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Abstract 

The  purpose  of  this  study  was  to  determine  the  feasibility  of  developing 
a  microcomputer  based  system  designed  for  use  by  enlisted  personnel  on-board 
a  U.S.  Navy  FBM  Submarine  Tender  in  producing  daily  high-priority  requisition 
"Hot  List"  reports.  These  reports  are  used  for  management  of  critical  repair 
jobs  on  FBM  Submarines  during  brief  refit  periods. 

Management  personnel  from  several  tenders  were  interviewed,  and  a  list 
of  requirements,  both  administrative,  and  user-oriented,  was  developed.  A 
software  application  using  dBASE  III  PLUS™  was  then  developed,  tested,  and 
validated.  Coding  developed  for  this  program  meets  or  exceeds  the  needs 
identified  during  the  interview  process,  and  includes  many  improvements  sug¬ 
gested  during  testing  and  validation. 

The  resulting  software  program  is  an  easy  to  install,  easy  to  use,  data 
base  report  program  designed  to  support  all  FBM  tenders  in  the  Atlantic  Fleet. 
Program  operation  does  not  require  knowledge  of  dBASE  by  the  user,  and 
entails  almost  no  training.  The  program  operates  on  a  PC-compatible  micro¬ 
computer  with  384K  RAM,  one  hard  disk  drive,  one  5V«"  floppy  disk  drive,  a 
monitor  (monochrome  or  coior).  and  an  80-column  printer  capable  of  using 
continuous  form  paper. 

Although  designed  specifically  for  FBM  Tenders,  alterations  to  the  soft¬ 
ware  could  allow  support  to  a  myriad  of  other  facilities,  including  other  types 
of  tenders.  Trident  Refit  Facilities,  shipyards,  and  other  repair  facilities  in 
the  DOD.  Improvements  in  both  customer  service  and  supply  management 
could  be  expected  in  these  arenas  through  implementation  of  this  program. 


SUPPLY  HOTLIST  REPORT  GENERATION  FOR 


FLEET  BALLISTIC  MISSILE  SUBMARINE  MANAGEMENT  MEETINGS 


I.  Introduction 


General  Background 

Fleet  Ballistic  Missile  (FBM)  Submarine  tenders  in  the  US  Navy  each  have 
a  mission  of  repairing  and  upgrading  FBM  submarines  and  their  components. 
Each  tender  provides  support  for  six  to  twelve  submarines,  where  normally 
one  to  three  are  in  port  at  any  one  time.  The  submarines  are  in-port  for  only 
about  one  month  during  "refits,"  and  the  deployment  dates  are  firm.  All 
repairs  must  be  made  during  the  refit,  as  the  submarines  will  be  deployed 
underwater  for  several  months  with  only  emergency  repair  facilities  available. 
FBM  submarines  receive  the  highest  priorities  within  the  supply  system  for 
requisitions  of  repair  parts  because  of  the  limited  repair  time  available  and 
the  criticality  of  their  missions. 

The  status  of  critical  requisitions  is  of  concern  to  many  of  the  superviso¬ 
ry  and  command  personnel,  as  it  may  impact  on  work  flow  and  the  completion 
of  required  work  throughout  the  refit.  During  this  time  the  "Ship's  Supervi¬ 
sor"  for  each  submarine  generates  approximately  400  work  orders,  of  vhich 
about  twenty  are  classified  as  critical,  or  "hot"  due  to  anticipated  unavailabili¬ 
ty  of  one  or  more  parts  by  the  scheduled  start  date  of  the  repair  job.  This 
poses  a  very  important  question:  how  do  those  responsible  for  ensuring  timely 
completion  of  critical  work  obtain  the  required  managerial  Information  on 


urgently  needed  parts? 


FBM  submarine  Tenders  presently  have  an  on-board  main  frame  computer 
system  that  is  used  for  a  variety  of  purposes,  called  the  shipboard  non-tactical 
automated  data  processing  program  (SNAP).  Included  In  the  functions  of  SNAP 
are  personnel  and  administrative  management,  a  repair  job-scheduling  system 
called  the  Integrated  Maintenance  Management  System  (IMMS),  and  an  auto¬ 
mated  supply  stock  inventory  system.  From  this  main-frame  system,  managers 
can  presently  obtain  information  such  as  chronological  listings  of  upcoming 
jobs,  and  on-board  availability  of  required  repair  parts.  The  Supply  Depart¬ 
ment  of  the  ship  is  notified  by  electronic  transmission  of  the  current  status 
of  high-priority  supply  requisitions,  but  the  information  is  received  in  hard¬ 
copy  form,  and  much  of  the  information  is  encoded  in  supply  lingo  that  is 
often  difficult  for  non-supply  personnel,  such  as  those  from  repair  shops,  to 
decipher.  In  the  next  few  paragraphs,  we  will  look  at  some  alternate  possibil¬ 
ities  for  providing  that  data  to  those  who  must  use  it  (9). 

Management  Information  Systems 

The  three  most  important  assets  of  an  organization  are  money,  people, 
and  data  (22:4).  In  a  Navy  environment,  the  budget  is  fairly  well  fixed,  and 
personnel  are  selected  and  provided  by  outside  organizations.  Efficient  and 
effective  management  of  data,  therefore,  provides  an  opportunity  to  overcome 
shortcomings  in  the  other  two  areas.  A  management  information  system  (MIS) 
that  will  assist  in  the  decision  making  process  by  collecting,  organizing,  stor¬ 
ing,  and  correlating  the  data  can  support,  and  sometimes  replace  other  assets 
that  are  in  short  supply  (22:5).  Such  an  MIS,  which  is  a  collection  of  data 
about  a  subject  that  can  be  manipulated  by  a  computer  to  provide  specific 
information  about  that  subject's  attributes  can  provide  that  information  to  a 
myriad  of  management  levels,  a  characteristic  Important  to  the  Navy  environ- 


ment  (13).  It  is  important,  however,  that  the  MIS  make  use  of  technological 
developments  as  they  become  available,  and  it  must  fit  the  style  of  the  organi¬ 
zation  and  those  using  it  (16:3). 

A  database,  which  is  a  "group  of  logically  related  files  or  data-sets" 
(16:131),  is  an  appropriate  target  for  a  MIS.  Computerized  database  manage¬ 
ment  systems  (DBMS)  have  been  used  in  organizational  management  in  large 
corporations  for  over  fifteen  years  (22:5).  The  recent  technological  advances 
in  the  area  of  microcomputers  has  made  once-cumbersome  databases  manageable 
within  a  small  shop  environment.  It  is  this  latter  step  that  brings  the  advan¬ 
tages  of  the  DBMS  to  the  Navy  shipboard  arena. 

The  term,  database,  can  have  many  meanings.  In  the  simplest  case,  It 
can  mean  a  list  of  data  on  a  piece  of  paper  or  in  a  computer  file  of  any  type. 
When  it  is  considered  to  mean  only  a  list  of  data,  however,  there  are  severe 
limits  to  the  ways  that  it  can  be  used.  To  find  information,  the  user  may 
have  to  manually  look  through  the  whole  list,  which  may  not  be  in  a  conve¬ 
nient  order.  If  there  are  data  associated  with  the  specific  item,  record,  or 
file  in  question  In  more  than  one  listing,  the  user  ray  then  have  to  perform 
another  search  through  the  other  list  or  lists.  Mathematical  relationships 
between  the  different  listings  may  also  have  to  be  performed  manually.  This 
can  be  both  awkward  and  time  consuming,  and  often  leads  to  errors. 

A  more  complex  form  of  a  database  involves  the  implementation  of  a 
computer.  In  this  case,  the  records  that  make  up  a  file  are  built  of  separate 
fields.  These  fields  are  consistent  in  size  (number  of  characters  or  digits) 
and  type  (numerical,  character,  date,  logical,  etc.)  for  each  record.  This 
allows  the  file  to  be  sorted  by  any  of  the  fields,  and  may  allow  mathematical 
relationships  to  be  built  between  separate  records  within  the  file.  In  this 


case,  the  size  of  a  file  is  usually  limited  to  the  size  of.  available  random 
access  memory  (RAM),  and  information  from  other  files  may  still  have  to  be 
input  or  related  manually. 

The  most  complex  database  commonly  available  for  both  micro  computers 
and  larger  mini  and  mainframe  computers  is  the  relational  database.  In  this 
case,  the  system  allows  the  various  database  flies  to  "talk"  to  each  other. 
Large  databases  that  relate  through  only  a  single  field  can  be  manipulated  to 
appear  as  one  even  larger  database.  Mathematical  and  associative  relations 
can  be  built  synergistically  that  provide  even  more  information  than  is  actually 
contained  in  the  individual  files.  Additionally,  since  all  files  do  not  have  to 
be  in  active  memory  at  all  times,  the  size  of  the  databases  is  limited  only  by 
the  size  of  the  mass  storage  device,  such  as  a  hard  disk  (10:1-3). 

The  MIS  tools  examined  above  can  be  applied  to  a  variety  of  management 
applications.  The  application  of  concern  here  is  that  of  resolving  the  problem 
of  a  lack  of  adequate  supply  high  priority  requisition  status  reports. 

Specific  Problem 

Reports  on  the  status  of  requisitions  for  critical  jobs  are  desired  by  each 
submarine  Commanding  Officer  (CO),  the  Tender  CO,  and  each  work  center 
in  the  Repair  Department  of  the  Tender,  as  well  as  the  high-priority  expediter 
in  the  Supply  Department  (2).  The  various  reports  are  generated  on  different 
frequencies,  due  to  the  various  need  of  the  customers.  The  reports  must  be 
based  on  the  same  data  base,  but  require  different  formats  and  emphasis  (14). 
Among  the  Tenders,  there  is  no  consistent  method  or  format  for  producing 
this  vital  information  in  an  efficient  and  usable  form. 


A  fleet-wide  standard  system  is  needed  which  uses  available  technology 
and  equipment  to  produce  uniform,  concise  reports  quickly  and  efficiently  (19). 


Importance  of  Research 

Presently,  on  one  Tender,  management  reports  are  produced  by  supply 
personnel  (who  have  little  experience  in  word  processing)  typing  required 
information  into  a  word  processor  using  an  awkward  and  cumbersome  software 
program,  then  rearranging  the  information  to  meet  the  requirements  of  each 
customer.  Due  to  the  complex,  error-prone,  and  time  consuming  nature  of 
the  task,  non-essential  reports,  such  as  a  Repair  Department  breakdown,  are 
presently  not  produced,  resulting  in  a  lower  level  of  customer  service  than 
the  Supply  Department  desires  to  provide  (23).  On  another  Tender,  the  coded 
supply  status  reports  that  are  sent  to  the  Tender  by  the  Polaris  Missile  Office, 
Atlantic  (PMOLANT)  are  given  directly  to  the  customer,  in  spite  of  the  read¬ 
ability  problems  for  non-supply  personnel  caused  by  using  supply  codes  rather 
than  plain  language.  The  reason  more  generically  understood  reports  are  not 
produced  by  this  tender  is  the  lack  of  an  easy  and  efficient  system  to  produce 
such  reports  (3).  A  third  tender  has,  in  fact,  implemented  a  simple  data  base 
management  system  that  allows  faster  input  of  data,  but  still  experiences  prob¬ 
lems  In  input  errors  and  one  single  report  output  format. 

Recent  decisions  to  upgrade  support  equipment  onboard  FBM  submarine 
tenders  have  resulted  in  procurement  of  IBM-compatible  microcomputers  and 
laser  printers  for  each  of  the  Tender  supply  departments  (19).  This  hardware 
provides  the  opportunity  to  upgrade  customer  support  capability  in  the  area 
of  hotlist  reporting  to  better  meet  the  needs  of  customers.  This  leaves  the 
concern  of  how  the  new  equipment  may  be  best  applied  to  support  fleet  needs" 

Research  Objectives 


Inherent  In  the  effective  utilization  of  management  information  svstom 
hardware  and  software  is  the  requirement  to  identify  those  needs  and  goals 
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one  has  for  the  system.  In  this  situation,  the  needs  and  goals  that  were  iden¬ 
tified  included  full  descriptions  of  the  needs  of  the  customers  (such  as  varying 
report  formats  and  reporting  frequencies)  and  specification  of  the  level  of  sup¬ 
port  to  be  provided  by  the  Supply  Department  (which  is  constrained  by  avail¬ 
able  skilled  manpower). 

Due  to  the  fleet-wide  need  for  a  reporting  system,  the  ultimate  goal  of 
this  thesis  is  to  produce  a  system  that  supports  those  needs. 


Research  Questions 


In  order  to  develop  or  acquire  a  report  generation  system  suitable  to 
meet  the  needs  of  the  FBM  Tenders,  a  series  of  questions  must  be  answered. 
Questions  considered  in  this  process  included,  but  were  not  limited  to,  the 
following: 

1.  What  systems,  report  formats,  and  forms  are  being  used  elsewhere 
in  the  Navy  to  meet  similar  requirements? 

2.  If  systems,  report  formats,  or  forms  are  available,  could  they  be 
adapted  for  use  here? 

3.  If  there  are  no  adaptable  systems  available,  could  a  procedure  be 
written  that  makes  use  of  available  technology  and  equipment? 

4.  If  a  new  system  or  procedure  is  developed  using  existing  computer 
hardware,  what  is  the  most  appropriate  software  basis  or  foundation? 

5.  If  a  new  system  or  procedure  is  developed,  what  criterion  and  con¬ 
cerns  must  be  considered  in  that  development  to  ensure  successful 
acceptance  and  implementation  in  the  fleet? 


Limitations 

This  research  effort  is  limited  to  systems  for  management  of  FBM  Sub¬ 
marine  refits  in  the  Atlantic  Fleet.  Tenders  doing  refits  of  non-FBM  subma¬ 
rines.  refits  of  surface  ships,  and  refits  In  the  Pacific  Fleet  may  use  similar 
procedures,  but  they  will  be  excluded  from  this  study  due  to  numerous  specific 
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differences  in  shipboard  organization,  policies,  schedule  patterns,  and  customer 
support  objectives. 

Furthermore,  the  intent  is  not  to  produce  a  system  that  can  be  used  for 
management  of  lower  priority  requisitions,  where  the  number  of  requisitions 
would  be  large  and  cumbersome,  but  one  more  appropriate  for  carefully  con¬ 
trolled  higher  priority  requisitions  such  as  those  critical  to  the  submarine 
refit  process. 

It  is  recognized  that  there  are  many  commercially  available  software 
packages  that  could  be  considered  mechanically  appropriate  for  the  purposes 
of  this  research.  Consideration  of  software  selection  has  been  limited  to  those 
available  to  the  Navy  through  routine  supply  procedures  and  policies. 

Assumptions 

The  following  assumptions  are  made  in  this  research: 

1.  A  set  of  significant  requirements  of  the  customers  can  be  developed 
that  applies  to  all  FBM  submarines  and  tenders. 

2.  The  needs  identified  for  the  CONUS  tenders  and  submarines  may¬ 
be  applied  to  those  homeported  out  of  Holy  Loch,  Scotland. 

3.  The  necessary  software  will  be  available  to  each  of  the  tenders  to 
allow  implementation  of  the  system  developed  as  a  result  of  this 
research. 

Thesis  Organization 

This  research  involves  development  of  a  software  program  for  use  in  the 
fleet,  as  well  as  historical  and  investigative  research  on  management  informa¬ 
tion  system  applications.  Additionally,  the  Navy  terminology  may  be  unfamiliar 
to  some  personnel  at  the  Air  Force  Institute  of  Technology.  As  a  result,  the 
chapters  of  this  thesis  follow  a  unique  pattern: 


Chapter  I:  Introduction 

Chapter  II:  Methodology 

Chapter  III:  Findings  and  Discussion 

Chapter  IV:  Program  Documentation 

Chapter  V:  Conclusions  and  Recommendations 

Appendix  A:  Program  Coding 

Appendix  B:  Glossary  of  Acronyms 

Appendix  C:  Definitions  of  Terms 

Appendix  D:  Interview  Questions 

Appendix  E:  Desk  Guide 
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II.  Methodolo 


Objectives 

In  order  to  meet  the  research  objectives  and  answer  the  research  ques¬ 
tions,  the  specific  needs  of  the  intended  customers  and  system  users  must  be 
recognized.  The  desired  end  product  is  a  microcomputer-based  software  pro¬ 
gram  on  a  5K"  "floppy  disk",  with  training  and  operating  documentation.  The 
program  has  been  designed  to  be  Implemented  on  each  FBM  submarine  Tender 
for  producing  reports  of  critical  requisitions  tailored  to  the  requirements  of 
each  customer. 

Investigation  of  these  questions  consisted  of  five  steps.  The  first  was 
a  literature  review  of  the  history,  characteristics,  and  applications  of  manage¬ 
ment  information  systems  and  database  management  systems,  both  commercially 
and  within  the  U.  S.  Navy.  This  provided  both  a  basis  for  employing  the 
appropriate  type  of  MIS,  and  information  for  selecting  the  most  suitable  soft¬ 
ware  package  for  this  application.  Second,  interviews  with  the  intended  key 
users  and  customers  of  the  system  were  conducted  to  determine  their  needs. 


Next,  an  acceptable  system  was  developed  using  the  selected  Appropriate  soft¬ 


ware  package,  and  documented.  Testing  of  that  system  was  then  performed 
using  Naval  Officers  familiar  with  the  shipboard  and  submarine  refit  environ¬ 
ments.  followed  by  validation  by  a  group  of  management  information 
experts  recommended  by  the  Department  Head  of  the  Resource  Management 
Division  of  the  AFIT  School  of  Systems  and  Logistics 


Definition  of  DBMS  Requirements 

A  literature  review  has  been  integrated  into  the  thesis  chapters  that 
involves  both  traditional  library  and  Navy  information  investigation,  as  well 
as  Interviews  with  experts  from  the  submarines  and  Tenders. 

Traditional  library  research  Included  both  library  reference  and  commer¬ 
cial  software  users  manuals  and  handbooks,  as  well  as  review  of  related 
theses. 

Investigation  of  MIS  and  DBMS  capabilities  and  availabilities  within  the 
Navy  included  requests  for  information  from  Navy  sources  such  as  the  Naval 
Supply  Systems  Command  Contracts  Directorate,  the  Naval  Regional  Data  Auto¬ 
mation  Center,  and  the  Naval  Data  Automation  Facility. 

Interviews  were  conducted  with  supply  personnel  responsible  for  generat¬ 
ing  the  reports,  and  with  officers  in  the  position  of  receiving  and  using  the 


reports. 


Research  resulting  in  the  requirement  to  develop  a  database  management 
system,  rather  than  adapting  an  existing  one,  has  required  that  further  analysis 
be  done  through  literature  research  and  considerations  of  available  software 


to  select  the  most  appropriate  database  management  development  software 
package  for  use  in  production  of  this  system. 


Interviews 


Unstructured  interviews  were  selected  as  the  major  source  of  primary 
data  for  this  research.  There  are  numerous  advantages  and  disadvantages  to 
obtaining  data  through  personal  interviews,  and,  in  this  case,  the  pros  clearly 


outweighed  the  cons. 

Disadvantages  to  using  the  interview  as  a  source  of  primary  data  include 
the  dependency  of  the  quality  of  information  on  the  willingness  of  the  source 


to  cooperate,  the  actual  knowledge  of  the  source,  communication  difficulties 
between  the  interviewer  and  the  source,  and  cost  (11:158-159).  In  this  situa¬ 
tion,  these  problems  were  minimal.  The  persons  being  interviewed  had  nothing 
to  lose,  but  much  to  gain  (a  better  management  system),  and  so  cooperated 
gladly.  Sources  for  this  information  were  carefully  selected  by  their  experi¬ 
ence  in  the  environment  where  the  DBMS  is  intended  to  operate,  and  can  be 
considered  experts  regarding  the  needs  of  that  environment.  Communication 
was  not  a  problem,  as  the  interviewer  has  significant  experience  in  the  operat¬ 
ing  environment  and  was  able  to  converse  in  the  lingo  peculiar  to  that  envi¬ 
ronment.  Due  to  the  limited  number  of  Interviews  planned,  and  the  availability 
of  the  AUTOVON  system  for  conducting  those  interviews,  cost,  which  is  often 
the  biggest  problem  in  personal  interviewing  (11:161)  was  not  a  concern. 

The  advantages  to  obtaining  data  in  this  manner  were  significant.  The 
interview,  and  especially  an  unstructured  personal  interview,  is  quite  versatile, 
and  allows  abstract  information  of  all  types  to  be  gathered  by  asking  only  a 
few  carefully  selected  questions  (11:158).  Furthermore,  the  interviewer  can 
have  an  effect  on  the  quality  of  the  information  gathered  by  explaining  ques¬ 
tions  and  probing  into  areas  that  may  reveal  more  information  (11:164). 

Unstructured  interviews  were  conducted  with  the  Supply  Officer  or  his 
representative,  and  Repair  Officer,  or  his  representative,  of  each  of  the  three 
active  FBM  Tenders  on  the  east  coast,  with  selected  Engineering  Officers  from 
available  FBM  submarines,  and  with  specific  personnel  from  the  Fleet  Polaris 
Missile  Office,  Atlantic  (PMOLANT)  who  are  Involved  in  the  generation  of 
input  data  or  the  analysis  of  performance  of  the  submarine  tenders.  Inter¬ 
views  with  submarine  personnel  took  place  with  those  Engineering  Officers 
whose  submarines  were  in-port  at  the  time  the  interview  process  took  place. 
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These  interviews  served  to  both  identify  existing  management  systems, 
and  to  ascertain  the  functional  requirements  that  the  fleet  has  for  such  a 
system.  Sample  interview  questions  are  shown  in  Appendix  C. 

Design  and  Development  of  DBMS 

A  system  was  then  designed  by  both  adapting  an  existing  system,  and 
programming  on  selected  software  such  that  it  meets  those  needs  identified 
in  the  Interviews  discussed  above.  The  resulting  system  is  formatted  on  a  5*4" 
floppy  disk,  and  is  accompanied  by  documentation  sufficient  to  train  and  assist 
personnel  who  are  acquainted  with  the  basic  use  of  a  microcomputer  in  the 
operation  of  the  program. 

The  system  is  designed  to  accept  input  of  basic  supply  status  data,  sort 
the  data  in  the  appropriate  order,  and  send  reports  in  various  formats  to  a 
connected  printer.  The  reports  that  result  have  been  designed  to  meet  the 
needs  of  those  customers  supported  by  the  Tender  Supplv  Department,  as  iden¬ 
tified  by  supply  and  repair  personnel  interviewed  during  the  literature  review. 
As  a  result,  after  inputting  status  data,  the  operator  may  merge  the  data  base 
with  built-in  supplementary  data  bases  to  obtain  definitions  of  supply  codes 
input  initially  with  the  data.  He  or  she  may  then  select  a  desired  report 
format.  The  program  will  re-sort  the  data  to  fit  that  report's  requirements, 
and  the  operator  may  then  print  the  report  whenever  i  specific  requirement 
arises.  The  system  has  been  designed  to  operate  on  a  menu-driven  basis, 
walking  the  operator  through  the  required  steps  to  produce  the  desired  reports. 

Field  Test 


Testing  was  conducted  with  Naval  officers  who  had  been  stationed  on¬ 
board  submarine  Tenders  in  Submarine  Supply  Assistance  Supply  Support  (SUB- 


SAT)  and  Repair  of  Other  Vessels  Supply  Support  (ROVSS)  division  officer 
capacities,  to  determine  both  the  utilization  of  the  system  from  the  point  of 
management,  and  the  suitability  from  the  point  of  the  sailors  who  will  operate 
it.  Required  improvements  identified  during  these  procedures  were  made,  and 
a  final  validation  made  by  the  AFIT  experts. 

Validation 

Validation  was  made  through  examination  by  database  management  experts 
at  the  Air  Force  Institute  of  Technology  (AFIT).  A  panel  of  experts  '.vas  rec¬ 
ommended  by  an  AFIT  faculty  member  who  specializes  in  the  area  of  computer 
software  operation  and  management.  The  experts  checked  the  program  opera¬ 
tion  and  documentation  to  determine  whether  it  met  the  needs  determined  to 


be  important  in  the  interview  portion  of  the  research,  and  to  determine  its 
operability  by  those  designated  to  use  it.  Improvements  recommended  by  those 
faculty  members  were  implemented  where  possible. 
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III.  Findings  and  Discussion 

In  Chapter  I,  five  specific  research  questions  were  identified  that  are 
considered  important  in  finding  a  way  to  meet  and  fulfill  the  needs  of  the 
fleet.  The  research  undertaken  here  has  answered  those  questions  in  the  fol¬ 
lowing  manner. 

Other  Systems 

Question  1:  What  systems  are  being  used  elsewhere  in  the  Navy  to  meet 

similar  requirements? 

A  basic  philosophy  within  the  Navy  is  one  of  independent  operation  of 
commands  in  areas  not  requiring  higher  level  management.  This  often  leads 
to  unique,  command-specific  solutions  to  identical  problems  occurring  in  many 
different  organizations.  The  Navy  has  had  a  Data  Automation  Command  (NAV- 
DAC)  for  many  years,  charged  with  the  mission  of  coordinating  standardized 
computer  hardware  and  software  throughout  the  Navy.  However,  applications 
as  minor  and  specialized  as  generation  of  a  local  report  that  is  not  required 
by  statute  or  regulation  are  frequently  handled  on  the  individual  command 
level,  rather  than  elevated  to  the  NAVDAC  level.  The  case  of  report  genera¬ 
tion  for  standard  information,  such  as  the  FBM  HOTLIST,  is  no  exception. 

There  are  three  FBM  submarine  Tenders  currently  active  in  the  Atlantic 
Fleet:  USS  Hunley  (AS  31),  USS  Holland  (AS  32),  and  USS  Canopus  (AS  34). 
Each  of  these  Tenders  generates  its  HOTLIST  through  a  different  technique. 
The  USS  Hunley  provides  the  encoded  HOTLIST  received  from  PMOLANT  to 
the  users  with  no  modifications,  changes,  or  updates  (3).  USS  Holland  person¬ 
alizes  the  HOTLIST  and  updates  it  by  writing  the  information  into  a  word  pro¬ 
cessing  file.  This  is  a  process  which  tends  to  be  cumbersome  and  error-prone, 
but  provides  the  advantage  of  being  able  to  add  locally-identified  updates  and 
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decode  some  supply  codes  (23).  USS  Canopus  takes  the  updating  a  step  fur¬ 
ther  by  inputting  information  into  a  simple  data  base  file,  somewhat  easing 
production  of  their  personalized  report,  but  still  risking  many  types  of  Input 
errors  (2). 

Among  other  activities  performing  REFIT  job  management  with  a  similar 
process,  other  methods  are  sometimes  used  to  produce  critical  requisition 
reports.  On  the  USS  Fulton,  an  attack-submarine  tender,  reports  are  produced 
using  a  different  word  processing  system  than  the  one  used  onboard  the  USS 
Holland.  The  HOTLIST  report  transmitted  from  PMOLANT  to  the  FBM  Tenders 
is  not  produced  for  attack-submarine  tenders,  and  all  information  must  be 
obtained  through  more  tedious  methods.  A  similar  report  is  produced,  however, 
three  times  per  week  for  the  refit  management  meetings  for  those  submarines 
(18). 

There  is  no  evidence  that  suggests  any  standardization  of  the  reports 
generated  for  the  management  meetings.  Although  a  report  which  includes 
the  basic  information  is  provided  by  PMOLANT  to  the  Tenders,  it  is  evident 
that  many  of  the  managers  involved  feel  the  need  for  an  upgrade  to  that 
report  in  order  to  satisfy  their  specific  updating  and  command-unique  require¬ 
ments.  It  is  also  evident  that,  although  each  of  these  personalized  reports 
approaches  the  point  of  meeting  the  needs  of  the  users,  most  users  would  like 
to  see  many  of  the  same  improvements  to  the  report.  Details  of  the  specific 
Improvements  desired  by  the  Tenders  are  discussed  in  more  detail  in  a  later 


part  of  this  chapter. 


Adaptability  of  Other  Systems 

Question  2:  If  systems,  report  formats,  or  forms  are  available,  could  they 

be  adapted  for  use  here? 

Systems  identified  in  this  research  used  a  variety  of  computer  hardware 
and  software. 

Most  local  systems  used  a  word  processing  software  package,  but  experi¬ 
enced  the  same  problems;  the  reports  were  difficult  to  update  or  change  in 
format,  and  tended  to  be  error- prone.  For  this  reason,  a  word  processing 
approach  is  not  considered  optimal. 

The  system  used  on  the  USS  Canopus  implemented  a  database  approach 
that  met  many  of  the  requirements  voiced  by  the  users  on  all  the  ships,  but 
had  been  converted  to  a  form  that  prevented  coding  examination  and  analysis. 
This  prevents  direct  adaptation  or  improvement  of  the  program,  but  certain 
input  and  output  aspects  of  the  program  can  be  identified  and  used  in  develop¬ 
ment  of  other  software. 

Use  of  Available  Technology  and  Equipment 

Question  3:  If  there  are  no  adaptable  systems  available,  could  a  procedure 

be  written  that  makes  use  of  available  technology  and  equip¬ 
ment? 

At  the  time  this  research  took  place,  each  FBM  Tender  had  on  order  a 
hardware  and  software  package,  developed  and  contracted  by  PMOLANT.  The 
packages  included  a  Zenith  Z248™  computer  with  one  floppy  disk  drive,  a 
20-Mg  hard  drive,  and  1  Mg  of  RAM,  to  be  used  for  SUBSAT  and  ROVSS 
application.  This  duplication  of  hardware  between  the  ships  makes  possible 
a  single  report  generator  for  all  FBM  Tenders. 

The  system  used  by  the  USS  Canopus  makes  use  of  a  popular  database 


management  software  package  that  lends  itself  to  producing  reports  from  field- 


oriented  data.  A  more  expanded  program  using  a  similar  software  package 
could  be  developed  that  considers  needs  identified  from  many  more  users. 

Software  Identification 

Question  4:  If  a  new  system  or  procedure  is  developed  using  existing  com¬ 

puter  hardware,  what  is  the  most  appropriate  software  basis 
or  foundation? 

Software  packages  that  were  considered  included  those  in  the  fields  of 
word  processing,  database  management,  integrated  packages,  and  programming 
languages. 

As  discussed  earlier,  word  processing  software  was  rejected  due  to  the 
difficulty  its  users  have  in  rearranging  data  to  produce  a  variety  of  reports, 
and  the  limited  ability  of  the  software  to  recognize  and  prevent  data  input 
errors.  Programming  using  a  programming  language  without  the  aid  of  a  soft¬ 
ware  package  is  not  only  time  consuming  to  the  initial  developer  in  writing 
sufficient  capability  into  the  program,  but  is  also  limiting  to  shipboard  person¬ 
nel  when  improvements  or  additions  are  desired  at  a  later  date.  Integrated 
packages  can  be  used  for  this  type  of  application,  but  the  part  of  the  inte¬ 
grated  package  that  would  be  used  would  be,  almost  exclusively,  the  database 
management  portion.  Using  an  integrated  package  for  this  application  fails 
to  take  advantage  of  the  multi-software  capabilities  that  are  the  purpose  of 
the  complexity  of  the  software.  Even  more  important,  if  limits  the  capabilities 
of  the  software  package  to  support  this  sort  of  application,  since  each  module 
of  the  package  is  reduced  in  capability  to  enable  the  large,  complex  package 
to  be  able  to  use  all  areas  interactively.  It  becomes  apparent  then,  that 
among  these  choices  of  readlly-avallable  software  packages,  the  more  appropri¬ 
ate  type  of  software  package  for  this  application  is  one  of  database  manage¬ 
ment.  This  type  of  software  allows  the  experienced  programmer  to  develop 


menu  and  input  screens  that  interact  and  accept  data  input  using  simple  inputs. 
Data  input  fields  can  be  controlled  as  to  the  size  and  type  of  input.  Each 
character  of  input  can  be  limited  to  numbers,  letters,  capitals,  and  other  con¬ 
trols.  Fields  can  be  related,  compared,  and  can  mathematically  interact  with 
each  other.  The  inexperienced  programmer  is  assisted  through  a  series  of 
menus  In  developing  lists,  reports,  and  other  manipulations  of  the  data.  This 
capability  will  allow  a  complex,  capable  program  to  be  written  that  can  later 
be  expanded  by  a  less  capable  operator. 

Among  the  available  database  management  software  packages,  there  is 
one,  dBASE  (by  Ashton-Tate),  that  is  currently  under  GSA  contract. 

DBASE  III00  and  dBASE  HI  PLUS™,  which  is  a  more-capable  upgrade  to 
dBASE  III“*>.  are  very  similar  in  capabilities  to  other  relational  database  man¬ 
agement  systems.  DBASE  III<R>  has  already  been  purchased  by  PMOLANT  as 
a  part  of  the  computer  packages  that  are  being  delivered  to  the  FBM  Tenders, 
and  can  be  inexpensively  upgraded  to  dBASE  III  PLUS™.  An  application 
designed  using  dBASE  coding  can  be  implemented  by  a  user  who  knows  nothing 
about  dBASE  itself  (1:12).  Because  of  the  availability,  the  capabilities  avail¬ 
able  in  the  "PLUS"  upgrade,  and  a  lack  of  significant  additional  capability 
by  other  programs,  dBASE  III  PLUS™,  was  selected  as  the  basic  software 
package  to  use  in  developing  the  HOTLIST  Report  Program  application. 

Development  Criteria 

Question  5:  If  a  new  system  or  procedure  is  developed,  what  criterion  and 

concerns  must  be  considered  in  that  development  to  ensure 
successful  acceptance  and  implementation  in  the  fleet" 

To  determine  the  needs  of  the  supply  and  repair  personnel  on  the  Ten¬ 
ders,  unstructured  interviews  were  held.  Questions  asked  included  such  issues 


as  are  included  in  Appendix  D.  Although  the  questions  began  at  these  issues. 


in  many  cases,  further  questions  were  asked  to  dig  deeper  into  the  needs  of 
these  users. 

The  criterion  identified  as  critical  system  capabilities  may  be  divided 
into  two  distinct  major  areas:  1)  reporting  requirements  of  the  supply  and 
repair  personnel  receiving  the  report,  and  2)  needs  of  the  program  operator. 

Reporting  Requirements.  Needs  expressed  by  the  officers  interviewed 
may  be  grouped  into  five  categories:  1)  end  use  of  report,  2)  recipients  the 
report  should  be  designed  for,  3)  fields  of  Information  desired  on  the  report, 
4)  periods  that  the  report  should  cover,  and  5)  operator-oriented  qualities  the 
system  should  provide. 

Presently,  the  Tenders  each  produce  only  one  standard  report  for  non¬ 
supply  customers,  and  only  one  Tender  produces  any  other  format.  Because 
of  this,  interviewees  tended  to  express  desires  for  an  end  product  in  relation 
to  one  "do-all"  report,  and  a  few  indicated  that  the  idea  of  using  several  tai¬ 
lored  mini-reports  was  difficult  to  comment  on,  as  they  had  only  had  the  one 
report  available  in  the  past  for  management. 

Report  End  Use.  There  were  three  primary  uses  identified  for  the 
Hot  List  report.  The  main  application,  presently  Implemented  on  all  Tenders, 
was  for  support  of  refit  management  meetings  at  CO  and  department  head 
levels.  Other  uses  identified  Included  Repair  Parts  Petty  Officer  (RPPO)  and 
Repair  division  requisition  tracking,  and  SUBSAT, ROVSS  expediter  requisition 
tracking  and  inventory  stock-checking. 

Report  Recipients.  There  is  presently  a  fairly  consistent  core  of 
Hot  List  report  recipients  throughout  the  FBM  squadrons.  Normally  included 
in  present  distribution  are:  squadron  Commodore,  Engineer,  and  Supply  Officer. 
Tender  CO,  Repair  Officer,  Production  Management  Assistant  (PMA).  Supply 


Officer,  ship  suptu  /isors,  and  SUBSAT  and  ROVSS  expediters,  and  in-port  sup- 
ported-unit  COs  and  Engineers.  Sometimes  included  in  the  distribution  list 
are:  squadron  Operations  and  Material  Officers,  Tender  Assistant  Supply  Offi¬ 
cer,  and  supply  transit-shed  officer.  In  some  cases,  the  Tender  Repair  Officer 
receives  several  copies  that  he  then  distributes  to  the  work  centers  or  Repair 
divisions  for  those  divisions  to  use  the  information  on  requisitions  affecting 
their  jobs  (2,  3,  17,  18,  21,  23). 

The  type  of  report  produced  was  found  to  influence  the  list  of  recipients. 
Most  interviewees  felt  that  RPPOs  and  specific  Repair  divisions  did  not  need 
the  entire  Hot  List  with  all  requisitions  for  all  jobs,  but  only  actually  needed 
information  pertaining  to  jobs  done  by  that  division.  Although  SUBSAT  and 
ROVSS  expediters  needed  information  from  the  entire  list  to  stock-check  out¬ 
standing  requirements,  this  function  did  not  require  availability  of  ail  standard 
information,  and  such  a  report  slowed  that  process  when  compared  to  a  report 
containing  only  a  list  of  needed  stock  numbers.  Transit-shed  officers  were 
also  sometimes  not  included  in  the  distribution  list  for  the  same  reason. 

Desired  Fields.  The  fields  of  information  desired  included  most  of 
those  presently  provided,  plus  several  not  currently  available  on  reports  from 
one  or  more  of  the  Tenders.  Data  field  desires  changed  somewhat  when  the 
possibility  of  tailored  mini-reports  was  Introduced. 

For  the  main  report,  for  use  by  squadron  and  supported-unit  officers, 
and  Tender  department  heads,  data  fields  desired  (broken  down  by  supported 
unit  and  sorted  by  requisition  priority  and  number)  included:  requisition  num¬ 
ber,  item  National  Stock  Number  (NSN).  nomenclature,  and  quantity,  job  con¬ 
trol  number  (JCN)  with  description,  and  requisition  status  information.  There 
was  a  unanimous  desire  to  show  requisition  status  and  action  activity  code 


information  in  plain  language  rather  than  the  codes  received  from  PMOLANT. 
but  current  capabilities  of  some  Tenders  made  those  translations  difficult  and 
error-prone,  especially  when  training  new  expediters. 

A  report  tailored  for  RPPOs  and  Repair  divisions  required  the  same  fields 
as  the  main  report,  but  sorted  in  a  different  manner.  In  these  cases,  the 
recipients  would  only  need  those  requisitions  pertaining  to  their  specific  work 
centers,  sorted  by  tended-unit  and  requisition  number. 

Expediters  needed  two  much  more  streamlined  reports,  covering  all  tended 
units  and  all  Repair  divisions,  for  the  purposes  of  querying  action  activities 
and  item  managers  on  the  current  status  of  requisitions,  and  stock-checking 
the  outstanding  stock  items  against  the  Tender’s  stock  receipts.  Use  of  the 
entire  main  Hot  List  for  this  purpose  was  inclined  to  slow  the  expediter's  work 
down,  as  the  expediter  was  required  to  flip  through  several  pages  to  obtain 
a  few  key  numbers. 

Additionally,  SUBSAT  and  ROVSS  officers  needed  a  streamlined  list  of 
those  requisitions  that  had  been  completed,  to  enable  analysis  and  identifica¬ 
tion  of  stocking  level  problems. 

Reporting  Periods.  Hot  Lists  are  presently  produced  daily  on  all 
FBM  Tenders  contacted,  and  by  PMOLANT.  This  frequency  met  the  minimum 
needs  of  all  of  the  interviewees.  One  of  the  PMAs  interviewed  (who  received 
Hot  Lists  that  were  produced  at  0600).  however,  commented  that  he  would  !.kc 
to  have  the  report  generated  later  in  the  day  on  days  when  there  was  a  refit 
management  meeting.  The  reason  the  report  was  produced  so  early  on  the 
ship  was  apparently  the  difficulty  in  updating  and  producing  it  quickly  (12). 
There  were  no  other  requests  for  any  changes  in  frequency  from  the  current 


dally  rate. 


System  Characteristics.  The  primary  concern  in  this  area  was  on 
the  subject  of  errors.  Many  of  those  interviewed  mentioned  the  tendency  for 
those  producing  the  report  to  make  mistakes  both  typographically,  and  in 
translation  of  supply  codes  to  plain  language.  Those  errors  not  only  inconven¬ 
ienced  those  trying  to  use  the  report,  but  also  resulted  in  extending  the  time 
required  to  produce  the  reports.  Errors  were  worst  on  the  Tenders  using  word 
processing  to  produce  the  reports. 

At  present,  none  of  the  systems  used  on  the  three  Tenders  in  this  study 
have  any  controls  to  verify  entry  or  assist  in  translation  of  codes. 

Needs  of  yie  Operator.  The  HOTLIST  Report  Program  was  developed  spe¬ 
cifically  for  operation  by  personnel  who  typically  are  assigned  the  task  of 
producing  such  reports  in  FBM  SUBSAT  and  ROVSS  offices.  These  personnel 
usually  hold  the  ranks  of  Seaman  (E-3)  through  First  Class  Petty  Officer 
(E-6),  and  are  normally  qualified  as  Storekeepers  (SK),  although  ROVSS  offices 
may,  at  times,  assign  Petty  Officers,  who  have  been  loaned  from  other  divi¬ 
sions  for  technical  assistance,  to  the  task.  These  personnel  usually  hold  tech¬ 
nical  ratings  such  as  Hull  Technician  (HT)  and  Electronics  Technician  (ET), 
and  may  be  somewhat  unfamiliar  with  supply  lingo  and  codes. 

System  Paradigm.  Efforts  were  made  in  the  development  of  the  HOTLIST 
Report  Program  to  identify  and  include  the  capabilities  of  the  system  necessary 
to  support  the  users,  as  identified  during  the  interviews  (21). 

Reports  were  designed  to  include  those  fields  of  data  identified  as  impor¬ 
tant  for  each  of  the  recipients.  The  top  level  management  report  for  REFIT 
management  meetings  was  designed  to  be  divided  into  one  section  for  each 
supported  unit,  sorted  by  requisition  priority  and  requisition  number.  The 
report  for  the  use  of  RPPOs  and  Repair  divisions  has  been  divided  by  work 


center,  and  sorted  by  supported  unit  and  requisition  number.  A  simple,  short 
report  was  designed  for  expediters  to  use  for  stock-checks,  listing  requisitions 
in  stock  number  order,  with  the  minimum  necessary  information. 

Included  in  development  considerations  was  a  concern  for  rapid  under¬ 
standing  of  the  requirements  of  each  screen.  A  main  emphasis  of  development 
of  this  software  was  the  interest  in  speeding  up  the  production  of  the  required 
reports  so  that  specialized  reports  and  unusual  printing  frequencies  could  be 
accommodated.  To  better  facilitate  this,  a  standard  screen  format  representa¬ 
tion  was  developed  so  that  the  user  would  not  be  required  to  adjust  to  a  dif¬ 
ferent  image  for  each  screen,  and  could  therefore  concentrate  on  the  contents 
of  the  screen. 

Also  of  prime  Importance  was  the  need  to  include  input  controls  wherever 
possible  as  a  measure  to  prevent  errors  by  the  user.  Many  of  the  intended 
users  will  have  little  or  no  experience  with  computer  operation,  and  these  con¬ 
trols  are  expected  to  reduce  their  initial  fear  of  possible  consequences  of 
erroneous  inputs,  and,  thus,  reduce  their  hesitancy  to  use  the  computer. 
Examples  of  the  controls  used  are  a  limitation  of  possible  responses  from  each 
menu  to  the  range  of  the  desired  inputs,  automatic  capitalization  of  many  of 
the  character  data,  and  a  limitation  to  numbers-oniy  for  certain  other  data 
inputs.  The  most  significant  of  the  controls,  automatic  translation  of  supply 
codes,  is  expected  to  eliminate  the  requirement  that  the  operator  be  highly 
familiar  with  the  meanings  of  supply  status  and  action  activity  codes,  and  even 
with  names  and  hull  numbers  of  supported  ships  and  submarines. 

The  result  of  these  efforts  was  an  easy-to-use,  comprehensive  report  gen¬ 
erator,  designed  for  junior  personnel  to  run  with  minimal  training. 
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Specifics  of  each  of  these  system  criterion  are  discussed  in  detail  as  they 
are  applied  to  the  software  in  Chapter  IV,  Program  Documentation.  Actual 
program  code  developed,  shown  in  Appendix  A,  uses  many  approaches  and  man¬ 
ipulations  of  basic  dBASE  III  PLUS  coding  (4,  5,  6,  7,  8,  10.  15.  20). 


IV.  Program  Documentation 


Program  Organization 

The  HOTLIST  Report  Program  has  been  written  for  use  in  conjunction 
with  Ashton  Tate's  dBASE  III  PLUS™  database  management  software,  using 
dBASE  coding.  All  coding  for  this  program  is  included  in  Appendix  A.  An 
overall  organization  chart  of  the  program,  showing  the  basic  relationships 
between  the  main  modules  is  shown  in  Figure  1. 


As  shown,  the  Main  Menu  provides  the  user  with  the  options  of  updating 
data,  removing  records,  translating  code  to  plain  English,  or  printing  reports. 
These  choices  lead  to  other  menus  that  allow  selection  and  operation  of  more 
specified  options  within  the  various  lower  level  modules. 

Introduction 

The  beginning  of  the  program  presents  the  Introductory  screens  shown 
in  Figures  2  and  3. 


HOTLIST  Report  Program 
Introduction 


HOTLIST  Report  Program  version  2.1 
Copyright  (c)  Claire  C.  Smith  1987.  All  Rights  Reserved. 

The  HOTLIST  Report  Program  is  an  easy-to-use  program  designed  to 
provide  U.  S.  Navy  SUBSAT  and  ROVSS  offices  with  a  simple  method 
by  which  they  may  input  critical  "Hot  List"  requisition  data, 
and  easily  generate  a  variety  of  reports  for  use  by  both  those 
involved  directly  in  'REFIT'  management  meetings,  and  also  those 
in  supply  who  expedite  the  requisitions. 

filter  FBM  Tender  UIC  to  continue  with  this  program 
OR 

Press  (RETURN)  to  EXIT  to  DOS 


UIC: 


Fig.  2.  Introductory  Screen 


At  this  point,  only  the  responses  of  a  five-number  Unit  Identification 
Code  (UIC)  or  <RETURN>  will  be  accepted  by  the  computer.  The  response, 
<RETURN>  will  cause  the  program  to  end,  and  will  cause  the  user  to  exit  from 


the  program,  and  go  to  the  Disk  Operating  System  (DOS)  prompt,  "C>."  A 


response  of  Inputting  the  Tender's  UIC  will  bring  up  the  screen  shown  in 
Figure  3. 


HOTLIST  Report  Program 
Rights  and  Warrantees 


***  RESTRICTS)  RIGHTS  WARNING  *** 

HOTLIST  Report  Program  is  a  copyrighted  package  designed  for  the 
exclusive  use  of  the  Uhited  States  Military,  and  is  protected  by 
U.  S,  Copyright  Law  (Title  17  United  States  Code).  Unauthorized 
reproduction  and/or  sales  may  result  in  imprisonment  of  up  to 
ONE  YEAR,  and  fines  of  up  to  $10,000  (17  USC  506).  Copyright 
infringers  may  also  be  subject  to  civil  liability. 

***  DISCLAIMER  OF  WARRANTEE  *** 

This  software  and  manual  is  distributed  without  any  express  or 
implied  warrantees  whatsoever.  Because  of  the  diversity  of  con¬ 
ditions  and  hardware  under  which  this  program  may  be  used,  no 
warrantee  of  fitness  for  a  particular  purpose  is  offered.  The 
user  is  advised  to  test  the  program  thoroughly  before  relying  cn 
it.  The  user  must  assune  the  entire  risk  of  using  the  program. 


Press  any  key  to  continue 

Copyright  (c)  Claire  C.  Smith  1987.  All  Rights  Reserved 


Fig.  3.  Rights  and  Warranties  Screen 


Operation  of  the  STARTUP  subroutine  that  produces  the  screens  shown 


In  Figures  2  and  3  is  made  from  within  the  MAINMENU  module.  A  flow  chart 
for  the  STARTUP  subprogram  is  shown  In  Figure  4. 
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Fig.  4.  STARTUP. prg  Flow  Chart 
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This  module,  which  Is  called  automatically  from  the  MAINMENU.prg  pro¬ 
gram,  Introduces  the  program,  offers  the  opportunity  to  exit  the  program, 
obtains  Information  necessary  to  tailor  reports  to  the  appropriate  Tender,  and 
provides  copyright  and  warrantee  Information.  When  these  functions  have  been 
completed,  program  functions  are  returned  to  the  MAINMENU  module. 

Main  Menu 

Entry  Into  the  program  following  the  first  two  screens  presents  the  user 
with  the  main  menu  screen  shown  in  Figure  5. 


HCrnJST  Report  Program  | 

Main  Menu  | 

Choose  Desired  Action  | 

[  1  ] 

Change  or  Add  To  Records  in  a  Data  Base  1 

[  2  ] 

Remove  or  Reactivate  Records  in  a  Data  Base  1 

[  3  ] 

Translate  supply  codes  for  reports 

[  4  ] 

Print  Reports 

[  0  ] 

Exit  the  HCTLIST  Report  Program 

filter  Choice  (0-4) :  0  1 

Fig.  5.  Main  Menu  Screen 

The  Main  Menu  screen  represents  the  top  level  operational  module  as 
shown  in  Figure  1.  In  this  module  (MAINMENU.prg),  the  user  is  given  the 


iff, 


opportunity  to  select  in  which  of  the  main  submodules  he  or  she  desires  to 
work.  A  selection  of  choices  <1>  through  <4>  will  send  the  user  to  the  begin¬ 
ning  of  the  next  module,  while  a  selection  of  <0>,  <RETURN>,  or  <ESC>  will 
cause  the  user  to  exit  directly  from  the  system  to  the  DOS  prompt.  It  should 
be  noted  that,  once  the  user  is  operating  within  the  program,  he  or  she  must 
return  to  this  screen  to  exit  from  the  HOTLIST  Report  Program. 

A  consideration  which  was  made  in  the  development  of  this  program  was 
the  concern  that  the  user  have  an  easy,  standardized  method  by  which  to 
quickly  move  to  higher-level  menus  and  exit  from  the  program.  This  was 
ensured  by  the  menu  standardization  that  predesignates  the  "exit  to  higher 
menu"  input  as  a  "0",  and  places  that  choice  at  the  end  of  the  screen.  In 
each  case,  entry  of  a  <0>,  <RETURN>,  or  <ESC>  will  move  the  user  to  the 
next  higher  level,  or,  in  the  case  of  the  MAINMENU  screen,  will  cause  the 
user  to  exit  the  program  (21). 

The  MAINMENU. prg  module  uses  the  logic  shown  in  the  flow  chart  in 
Figure  6,  which  is  simply  a  selection  of  a  "CASE"  from  among  several  choices. 
This  operates  in  a  similar  fashion  to  a  series  of  "IF"  statements  used  in  most 


programming  languages. 


OPTION  =  0 


Exit  Prograi 


OPTION  =  1 


Change  or  Add 
To  Data  Base 
DATACIC.prg 


OPTION  =  2 


Change  Record 
Active  Status 
DAT  ADEL. prg 


OPTION  =  3 


Translate  Codes 
RELATE. prg 


OPTION  =  < 


Print  Rep  rts 
LISTREPS.prg 


Fig.  6.  MAINMENU.prg  Flow  Chart 


Change  or  Add  to  Records  in  a  Data  Base 


A  selection  of  choice  <1>  In  the  Main  Menu  will  move  the  user  to  the 
menu  screen  shown  in  Figure  7.  Here,  the  user  Is  given  a  choice  of  data 
bases  to  which  he  or  she  may  add  or  make  a  change. 


BC7ILIST  Report  Program 
Change  or  Add  To  Records  in  a  Data  Base 


Select  the  Data  Base  you  want  to  Change 
[  1  ]  HOTLIST 

[  2  ]  Supply  Status  Codes 

[  3  ]  Action  Activity  Codes 

(  4  ]  U  I  C  s 

[  0  ]  Return  to  Main  Menu 


Enter  Choice  (0-4) :  0 


Fig.  7.  DATACHG.prg  Change  Data  Base  Selection  Menu 


This  menu,  as  with  the  main  menu,  operates  through  a  simple  CASE 
choice.  Selection  of  <0>,  <RETURN>,  or  <ESC>  will  move  the  user  back  to 
the  previous  screen,  the  Main  Menu.  Selection  of  a  specific  data  base  will 
move  the  user  to  the  beginning  of  one  of  the  subordinate  sub-modules  that 
are  displayed  in  the  chart  in  Figure  8. 


Change  or  Add  to  Records  in  HOTL1ST.  Selection  of  Option  <1>  In  the 

DATACHG  menu  will  move  the  user  Into  the  submodule  In  which  he  or  she 

may  change  or  add  to  records  in  the  main  HOTL1ST  data  base,  and  open  HOT- 
LIST.  dbf  data  base  and  all  associated  Indexes.  In  this  module,  the  user  is 
first  asked  for  the  requisition  Julian  date  associated  with  the  record  the 

user  wishes  to  add  to  or  change.  It  is  not  necessary  that  the  user  know 

whether  or  not  the  record  is  in  the  database.  Only  number  entries  or  a  <RE- 
TURN>  are  accepted  as  input.  An  entry  of  <RETURN>  will  close  all  open 
database  files  and  bring  the  user  back  to  the  data  base  selection  menu  (Fig¬ 
ure  7).  An  entry  of  a  Julian  date  moves  the  user  into  the  module.  Figure  10 
shows  the  screen  that  requests  the  date. 


HOTLIST  Report  Program 
Change  or  Add  To  Records  in  HJTLIST 


Biter  Requisition  Julian  Date:  0 


To  return  to  menu,  just  press  (RETURN) 


* 


Fig.  10.  Requisition  Date  Query  Screen 


At  this  point,  the  program  filters  the  data  base  so  that  only  records  with 
the  specified  date  will  be  considered  for  the  update.  The  user  is  then  pre¬ 
sented  with  the  screen  in  Figure  11,  which  requests  the  four-digit  requisition 
aerial  number. 


Fig.  11.  Requisition  Serial  Query  Screen 

Serial  number  entries  may  have  letters  or  numbers  in  the  first  three 
spaces,  but  only  numbers  in  the  fourth,  to  accommodate  serial  numbering  sys¬ 
tems  In  the  FBM  supply  system.  Upon  entry,  the  program  looks  for  that  num¬ 
ber  from  among  the  records  that  have  the  Julian  date  entered  In  the  previous 
screen. 
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If  the  requisition  number  Is  not  In  the  database,  the  user  Is  Informed 
of  that  fact,  and  given  the  opportunity  to  create  a  new  record,  as  shown  In 
Figure  12. 


Fig.  12.  Requisition  Not  Found  Screen 

Only  the  entries  <Y>,  <N>,  and  <RETURN>  are  accepted  by  the  computer. 
If  the  user  enters  <N>,  the  requisition  date  query  screen  (Figure  10)  is 
returned  to  allow  entry  of  another  record.  The  default  answer  is  preset  at 
<Y>,  so  either  <Y>  or  <RETURN>  will  bring  up  a  data  Input  screen,  as  shown 
In  Figure  13. 


HOOLIST  Report  Program 
Add  or  Update  Requisition  Information 

Requisition  Information 

UIC:  JULIAN  DATE:  9999  SERIAL  #:  W999  NUN: 

PRIORITY  (Use  X  for  sped,  exp.):  NOMENCLATURE: 

QTY:  0  U/I:  ENDUSER:  NIS/PNIS/NC/NS: 

Job  Information 


JOB  NAME: 


WORK  CENTER: 


Status  Information 


STATUS  CODE:  ACTION  ACTIVITY: 

REMARKS  (Contract  Number,  ESD,  EDO,  etc.): 


Press  < ENTER)  after  entry  if  cursor  does  not  move  to  next  field. 
Press  <ESC>  to  finish  edit. 


Fig.  13.  HOTLIST  Data  Input  Screen 


If  the  requisition  was  found  in  the  data  base,  but  has  been  given  an 
"inactive"  status  through  the  "Remove  Records"  module,  the  screen  will  show 
that  status,  as  shown  in  Figure  14.  The  default  input  for  this  screen  Is  <N>, 
as  a  <Y>  will  delete  information  In  that  record  and  present  a  screen  with 
blank  data  fields,  as  in  Figure  13. 
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HCfTUST  Report  Program 
Add  or  Update  Requisition  Information 


Requisition  Information 


UIC:  04720  JULIAN  DATE:  9999  SERIAL  f:  V999  NUN:  00-215-8442 
PRIORITY  (Use  X  for  specl.  exp.):  1  NOMENCLATURE:  NUT  LOCKING 
CflY:  25  U/I:  DZ  INDUS®:  B  DIV  NIS/PNIS/NC/NS:  NIS  TSN:  6273 


Job  Information 

JOB  NAME:  (1  MG 

WORK  CENT®:  EA01 

JSN:  0293 

Status  Information 


STATUS  OQOE:  BV  ACTION  ACTIVITY:  S9I 

ROARKS  (Contract  Nunber,  ESD,  EDO,  etc.): 

ESD  14  Jun  87.  Contract  No.  N00002-86-M-5183.  Air  shipment  expected 


Press  <ENT®>  after  entry  if  cursor  does  not  move  to  next  field. 
Press  <ESC>  to  finish  edit. 


Fig.  15.  HOTLIST  Data  Update  Screen 

Data  entry  In  this  screen  Is  controlled  for  each  of  the  data  fields.  As 
the  user  completes  each  field,  the  cursor  Is  sent  to  the  next  field.  Where 
appropriate,  entries  are  limited  to  numbers  only,  and  letters  are  automatically 
capitalized.  Most  of  the  information  is  taken  from  either  the  requisition  input 
Information  from  the  ordering  activity,  or  the  Hot  List  status  report  from 
PMOLANT.  When  the  last  field  on  the  screen  Is  completed,  or  upon  Input  of 
the  <ESC>  key,  the  data  field  portion  remains  the  same,  while  the  bottom 
block  of  the  screen  changes  to  the  line  shown  in  Figure  16. 


HOTLIST  Report  Program 
Add  or  Update  Requisition  Information 

Requisition  Information 

UIC:  04720  JULIAN  DATE:  9999  SERIAL  f:  W999  NIIN:  00-215-8442 
PRIORITY  (Use  X  for  specl.  exp.):  1  NOMENCLATURE:  NUT  LOCKING 
QTY:  25  U/I:  DZ  ENDU5ER:  B  D1V  NIS/PNIS/NC/NS:  NIS  TSN:  6273 


Job  Information 


JOB  NAME:  #1  MG 


WORK  CENTER:  EA01 


JSN:  0293 


Status  Information 


STATUS  CODE:  BV  ACTION  ACTIVITY:  S9I 

REMARKS  (Contract  Nunber,  ESD,  EH),  etc.): 

BSD  14  Jun  87.  Contract  No.  N00002-86-M-5183.  Air  shipment  expected 
Is  input  OK?  (  Y  or  N  )  (  <ESC>  to  QUIT  )  N 


Fig.  16.  HOTLIST  Input  Verification  Screen 


At  this  point,  the  user  has  four  possible  entries.  An  entry  of  <ESC>  will 
return  the  user  to  the  requisition  date  Input  screen  without  saving  any  of  the 
data  Input  Into  the  HOTLIST  Data  Update  screen.  <N>  or  <RETURN>  will 
retain  the  update  screen  with  the  data,  and  move  the  cursor  back  to  the  first 
field  of  entry.  <Y>  will  place  all  data  shown  on  the  screen  Into  a  record  In 
the  HOTLIST  data  base,  and  return  the  user  to  the  requisition  date  input 
screen  for  further  record  updates. 

A  flow  chart  of  the  submodule  to  change  or  add  to  HOTLIST  records 
(HOTCHG.prg)  Is  shown  In  Figure  17. 


SET  BOTLIST 
Data  input  , 


verify  Entry 


<ESC>  Kay? 


Change  or  Add  to  Supply  Status  Records.  From  the  Change  Data  Base 
Selection  Menu,  option  <2>  will  enter  the  submodule  to  change  or  add  to  the 
supply  status  code  data  base,  and  open  STATUS. dbf  and  all  related  indexes. 
This  data  base  Is  used  to  provide  definitions  of  supply  status  codes  automatic¬ 
ally  to  the  reports.  The  user  is  first  asked  for  the  two-digit  status  code  to 
change,  on  the  screen  shown  in  Figure  18.  It  is  not  necessary  that  the  user 
know  whether  or  not  the  record  Is  In  the  database.  An  entry  of  <RETURN> 
will  close  all  open  database  files  and  bring  the  user  back  to  the  data  base 
selection  menu  (Figure  7).  An  entry  of  the  status  code  will  move  the  user 
into  the  module. 


Fig.  18.  Status  Code  Query  Screen 
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I  i.n  I, 


Status  code  Inputs  accepted  may  be  either  letters  or  numbers,  but  all 
letter  Inputs  are  automatically  capitalized.  Upon  entry,  the  program  looks  for 
the  file  with  that  status  code. 

If  the  status  code  is  not  In  the  database,  the  user  Is  Informed,  and  given 
the  opportunity  to  create  a  new  record,  as  shown  In  Figure  19. 


HCTLIST  Report  Program 
Add  To  or  Change  STATUS  CODES 


Biter  Status  Code:  CL 


Status  code  not  found. 


Do  you  want  to  create  a  new  record?  (Y  or  N> 


Fig.  19.  Status  Code  Not  Found  Screen 


Only  the  entries  <Y>,  <N>,  and  <RETURN>  are  accepted  by  the  computer. 
If  the  user  enters  <N>,  the  status  code  query  screen  (Figure  18)  is  returned 
to  allow  entry  of  another  record.  The  default  answer  Is  preset  at  <Y>,  so 
either  <Y>  or  <RETURN>  will  bring  up  a  data  input  screen,  as  shown  In  Fig¬ 


ure  20. 
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HOTLIST  Report  Program 
Add  or  Update  Status  Codes 


Status  Code:  CJ 

Leading  Service  (Navy,  Amy,  All,  Etc):  All 
Description  of  Status: 

Rejected;  obsolete.  Request  sub  on  new  doc  or  same  item  on  1348-6. 


Is  input  OK?  {  Y  or  N  )  (  <ESC>  to  QUIT  )  N 


Fig.  20.  Status  Code  Input/Update  Screen 

If  the  status  code  was  found  in  the  data  base,  but  has  been  given  an 
"Inactive"  status  through  the  "Remove  Records"  module,  the  screen  will  show 
that  status,  as  shown  In  Figure  21.  The  default  input  for  this  screen  is  <N>, 
as  a  <Y>  will  delete  information  in  that  record  and  present  a  screen  that  looks 
like  the  one  In  Figure  20.  with  blank  data  fields.  If  the  record  was  found, 
the  status  will  be  displayed  for  edit,  as  In  Figure  20.  In  this  screen.  "Leading 
Service"  Inputs  are  limited  to  four  alpha-characters,  and  the  first  will  be  auto¬ 
matically  capitalized.  For  the  "Description"  entry,  a  sixty-eight  character 
Input  In  any  combination  of  letters  and  numbers  is  allowed.  Entry  verification 
works  the  same  way  as  It  does  in  the  HOTCHG.prg  module  (as  described  fol¬ 
lowing  Figure  16). 
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HOTLIST  Report  Program 
Add  To  or  Change  STATUS  CODES 


Biter  Status  Code:  CJ 


This  status  code  has  been  deleted  frcm  current  files. 

Do  you  want  to  use  it  anyway?  (Y  or  N) 

WARNING:  Data  presently  in  record  will  be  lost  unless  record  is 
'Uhdeleted  first  using  'Delete  or  Uhdelete  Records'  Module. 


Fig.  21.  Status  Code  Inactive  Screen 


A  flow  chart  of  the  submodule  to  change  or  add  to  Status  Code  records 


(STATCHG.prg)  Is  shown  In  Figure  22. 


i 

t£  Change  or  Add  to  Activity  Code  Records.  From  the  Change  Data  Base 

f  Selection  Menu,  option  <3>  will  enter  the  submodule  to  change  or  add  to  the 

j  activity  code  data  base,  and  open  ACTIVITY. dbf  and  all  of  Its  related  Indexes, 

jj  This  data  base  Is  used  to  provide  definitions  of  action  activity  codes  automatl- 

i  cally  for  the  reports.  The  user  is  first  asked  for  the  three-digit  activity  code 

?  to  change,  on  the  screen  shown  in  Figure  23.  An  entry  of  <RETURN>  will 

;\  close  all  open  database  files  and  bring  the  user  back  to  the  data  base  selection 

p 

(menu  (Figure  7).  It  Is  not  necessary  that  the  user  know  whether  or  not  the 
’  record  Is  In  the  database. 


Action  activity  code  inputs  accepted  may  be  either  letters  or  numbers, 
but  all  letter  inputs  are  automatically  capitalized.  Upon  entry,  the  program 
looks  for  the  file  with  that  action  activity  code. 

If  the  action  activity  code  is  not  in  the  database,  the  user  is  informed, 
and  given  the  opportunity  to  create  a  new  record,  as  shown  in  Figure  24. 


£ 


B 

► 

% 


Fig.  24.  Action  Activity  Code  Not  Found  Screen 

Only  the  entries  <Y>,  <N>,  and  <RETURN>  are  accepted  by  the  computer. 
If  the  user  enters  <N>,  the  action  activity  code  query  screen  (Figure  23)  is 
returned  to  allow  entry  of  another  record.  The  default  answer  is  preset  at 
<Y>,  so  either  <Y>  or  <RETURN>  will  bring  up  a  data  input  screen,  as  shown 
in  Figure  25. 
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HOILIST  Report  Program 
Add  or  Update  Action  Activity  Codes 


Action  Activity  Code:  NRZ 


Name  of  Action  Activity:  NSC  Charleston 


Is  input  OK?  (  Y  or  N  )  (  <ESC>  to  QUIT  )  N 


Fig.  25.  Action  Activity  Code  Input/Update  Screen 


If  tiie  action  activity  code  was  found  in  the  data  base,  but  has  been 


given  an  "inactive"  status  through  the  "Remove  Records"  module,  the  screen 


will  show  that  status,  as  shown  in  Figure  26.  The  default  input  for  this 


screen  is  <N>,  as  a  <Y>  will  delete  information  in  that  record  and  present  a 


screen  that  looks  like  the  one  in  Figure  25,  with  blank  data  fields,  if  the 


record  was  found,  the  status  will  be  displayed  for  edit,  as  in  Figure  25.  In 


this  screen,  "Name  of  Action  Activity"  Inputs  are  limited  to  twenty  characters 


in  any  combination  of  letters  and  numbers.  Entry  verification  works  the  same 


way  as  it  does  in  the  HOTCHG.prg  module  (as  described  following  Figure  16). 


The  verification  line  is  shown  in  Figure  25. 
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HOTLIST  Report  Program 
Add  To  or  Change  ACTICN  ACTIVITY  Codes 


Biter  Action  Activity  Code:  NRZ 


This  Action  Activity  code  has  been  deleted  from  current  files. 
Do  you  want  to  use  it  anyway?  (Y  or  N ) 


WARNING:  Data  presently  in  record  will  be  lost  unless  record  is 
'Undeleted  first  using  'Delete  or  Undelete  Records'  Nodule. 


Open  Files 


k — 


ACTIVITY. dbf 
and  INDEXES 


N 


Never 

False 


I 


i 

i 

i 
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Fig.  27.  ACTYCHG.prg  Flow  Chart 


Change  or  Add  to  Unit  Identification  Code  (UIC)  Records.  From  the 
Change  Data  Base  Selection  Menu,  option  <4>  will  enter  the  submodule  to 
change  or  add  to  the  UIC  data  base,  and  open  UIC.dbf  and  all  related  indexes. 
This  data  base  is  used  to  automatically  provide  ship  names  and  hull  numbers 
in  relation  to  UICs  in  the  reports.  The  user  is  first  asked  for  the  five-digit 
UIC  to  change,  on  the  screen  shown  in  Figure  28.  An  entry  of  <RETURN> 
will  close  all  open  database  files  and  bring  the  user  back  to  the  data  base 
selection  menu  (Figure  7).  It  is  not  necessary  that  the  user  know  whether 
or  not  the  record  is  in  the  database. 
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If  the  UIC  Is  not  In  the  database,  the  user  Is  informed,  and  given  the 
opportunity  to  create  a  new  record,  as  shown  in  Figure  29. 


Fig.  29.  UIC  Not  Found  Screen 


Only  the  entries  <Y>,  <N>,  and  <RETURN>  are  accepted  by  the  computer. 
If  the  user  enters  <N>,  the  UIC  query  screen  (Figure  28)  is  returned  to  allow 
entry  of  another  record.  The  default  answer  is  preset  at  <Y>,  so  either  <Y> 
or  <RETURN>  will  bring  up  a  data  input  screen,  as  shown  in  Figure  30. 
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HOTLIST  Report  Program 
Add  or  Update  UICs 


UIC:  04720  Name  of  Ship:  USS  CANOPUS 

Type  of  Ship  (SSBN,  SSN,  AS,  etc.):  AS  Dull  Nimber:  34 


same 

16). 


way  It  does  in  the  HOTCHG.prg  module  (as  described  following  Figure ' 
The  verification  line  is  shown  in  Figure  30. 


Fig.  31.  UIC  Inactive  Screen 


A  flow  chart  of  the  submodule  to  change  or  add  to  UIC  records  (UIC- 


CHG.prg)  Is  shown  In  Figure  32. 


Verify  Entry 


New  UIC? 


Add 

Record  to 
uic.dbf 


Remove  or  Replace  Records  in  a  Data  Base 


A  selection  of  <2>  from  the  Main  Menu  moves  the  user  to  the  menu 
screen  shown  In  Figure  33.  This  menu  operates  In  an  Identical  manner  to  the 
DATACHG.prg  menu.  Selection  of  <0>,  <RETURN>,  or  <ESC>  will  move  the 
user  back  to  the  previous  screen,  the  Main  Menu. 


Fig.  33.  DATADEL.prg  Remove/ Replace  Records  Selection  Menu 


Selection  of  a  specific  data  base  will  move  the  user  to  the  beginning  of 
one  of  the  submodules  that  are  displayed  in  the  chart  in  Figure  34. 
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OPTION  =  0 


OPTION  =  1 


OPTION  i  2 


OPTION  =  3 


OPTION  = 


Upturn  To 
Main  Menu 


Change  botlist 
Active  Status 
HOTDEL.prg 


Change  Supply 
Status  Code 
Active  Status 
STATDEl.prg 


Change  Action 
Activity  Code 
Active  status 
ACTYOEL.prg 


Change  U1C  Code 
Active  Status 
UICDEL.prg 


Fig.  35.  DATADEL.prg  Flow  Chart 
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HOTLIST  Report  Program 
Remove  or  Reactivate  Records  from  HOTLIST 


Filter  Requisition  Julian  Date:  9999 


Filter  Four-digit  Requisition  Serial  tfcnber: 


BJTLIST  Report  Program 

2J 

« 

Remove  or  Reactivate  Records  fran  HCflLIST 

>2 

Qiter  Requisition  Julian  Date:  9999 

i 

Biter  Four-digit  Requisition  Serial  Member:  W999 

a 

,v" 

That  requisition  mmber  is  not  cn  the  HOTLIST 

5 

> 

S 

I  Press  any  key  to  continue 

■V 

Fig.  38.  Requisition  Not  Found  Screen 

If  the  requisition  is  in  the  data  base,  either  in  an  "inactive"  or  an 
"active"  status,  the  record  is  then  displayed  for  the  examination  of  the  user. 

If  the  record  is  inactive,  the  user  is  asked  if  he  or  she  wishes  to  reacti¬ 
vate  it.  as  shown  In  Figure  39.  A  reply  of  <Y>,  <RETURN>  or  <ESC>  will 
return  the  record  to  an  active  status.  A  reply  of  <N>  will  place  the  record 


in  an  Inactive  status. 


Fig.  39.  HOTDEL.prg  Record  Inactive  Screen 


Removing  an  active  record  Is  more  complex,  to  prevent  Inadvertent 
removal  of  current  records.  Initially,  the  record  Is  brought  up  for  examination 
of  the  viewer,  as  with  those  to  be  reactivated,  and  the  user  is  informed  of 
the  record's  "active"  status.  The  user  is  given  the  opportunity  to  reply  with 
an  <N>,  <ESC>,  or  <RETURN>,  any  of  which  will  return  them  to  the  Julian 
date  Input  screen.  If  the  user  presses  <Y>,  the  question,  "Are  you  sure?"  will 
be  added  to  the  screen,  as  shown  in  Figure  40.  Again,  a  reply  of  <N>,  <ESC>, 
or  <RETURN>,  will  return  the  user  to  the  Julian  date  input  screen,  with  no 
change  to  the  status  of  the  record.  A  reply  of  <Y>  will  put  the  record  into 
an  "Inactive"  status,  and  the  user  will  be  Informed  by  a  message  at  the  bottom 
of  the  screen,  as  shown  in  Figure  41. 
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HCTLIST  Report  Program 
Remove  or  Reactivate  HCTLIST  Records 


Requisition  Information 

UIC:  04720  JULIAN  DATE:  9999  SERIAL  I:  W999  NIIN:  00-215-8442 
PRIORITY  (Use  X  for  specl.  exp.):  1  NOMENCLATURE:  NOT  LOCKING 
QTY:  25  U/I:  DZ  ENDUSER:  B  DIV  NIS/PNIS/NC/NS:  NIS  TSN:  6273 


Job  Information 


JOB  NAME:  «1  MG 


WORK  CENTER:  EA01 


JSN:  0293 


Status  Information 

STATUS  COCE:  BV  ACTION  ACTTVITY:  S9I 

REMARKS  (Contract  (Amber,  ESD,  EDO,  etc.): 

ESD  14  Jun  87.  Contract  No.  M00002-86-M-5183.  Air  shipment  expecte 


RECORD  IS  CURRENTLY  ACTIVE.  WANT  TO  REMOVE?  (Y  or  N)  Y 
Are  you  SURE?  (Y  or  N)  N 


Fig.  40.  HOTDEL.prg  Record  Active  Screen 


HCTLIST  Report  Program 
Remove  or  Reactivate  HCTLIST  Records 


Requisition  Information 

UIC:  04720  JULIAN  DATE:  9999  SERIAL  #:  W999  NIIN:  00-215-8442 
PRIORITY  (Use  X  for  specl.  exp.):  1  NOMENCLATURE:  NOT  LOCKING 
<7TY:  25  U/I:  DZ  ENDUSER:  B  DIV  NIS/PNIS/NC/NS:  NIS  TSN:  6273 


Job  Information 


JOB  NAME:  #1  MG 


WORK  CENTER:  EA01 


JSN:  0293 


Status  Information 


STATUS  CODE:  BV  ACTION  ACTTVITY:  S9I 

REMARKS  (Contract  (Amber,  ESD,  EDD,  etc.): 

ESD  14  Jun  87.  Contract  No.  N00002-86-M-5183.  Air  shipment  expecte 


Record  has  been  removed.  Press  any  key  to  continue 


HOTDEL.prg  Removal  Completed  Screen 


A  flow  chart  of  the  submodule  to  remove  or  replace  HOTLIST  records 
(HOTDEL.prg)  is  shown  in  Figure  42. 


DATADEL.prg 


Fig.  42.  HOTDEL.prg  Flow  Chart 
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Continued 
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Remove  or  Replace  Supply  Code  Records.  From  the  Remove' Replace  Rec¬ 
ords  Menu,  the  other  three  data  bases  may  also  be  accessed  for  this  purpose. 
It  is  unlikely  that  these  data  bases  wiil  require  more  than  occasional  manage¬ 
ment  of  this  type,  but  there  may  be  occasion  that  requires  the  user  to  render 
one  of  the  records  inactive.  Supply  status  codes  may  be  created  for  local  use, 
then  deactivated  as  they  are  replaced  by  service  wide  codes  with  the  same 
message.  Action  Activities  may  become  deactivated.  UICs  may  be  associated 
with  ships  that  are  decommissioned.  Part  of  the  program  operates  by  associat¬ 
ing  the  supported  unit's  hull  number  (from  the  UIC.dbf  Data  Base)  with  the 
name  of  the  ship.  Although  highly  unlikely,  there  may,  at  some  time,  be  a 
situation  where  a  Tender  supports  a  non-SSBN  ship  that  has  a  hull  number 
that  is  the  same  as  one  of  the  ships  on  the  data  base.  As  it  is  even  more 
unlikely  that  the  Tender  would  be  also  supporting  that  SSBN  at  the  same  time, 
the  user  would  be  able  to  create  the  new  hull  number  record,  and  remove  the 
old  one,  allowing  the  program  to  support  the  special  unit. 

Figures  43,  44,  and  45  show  input  screens  for  each  of  the  data  bases. 

Figures  46,  47,  and  48  show  the  message  provided  when  the  record  cannot 
be  found  in  the  data  base.  In  each  case,  pressing  a  key  following  these 
screens  returns  the  user  to  a  blank  input  screen  for  that  data  base. 

Figures  49  through  54  show  the  screen  sequence  for  the  three  data  bases 
when  the  record  has  Deen  found  in  an  inactive  status,  and  the  user  desires 
to  reactivate  that  record. 

Figures  55  through  60  show  the  screen  sequence  for  the  three  data  bases 
when  the  record  has  been  found  in  an  active  status,  and  the  user  desires  to 
remove  that  record. 
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Fig.  43.  Status  Code  Record  Input  Screen 


Fig.  44.  Action  Activity  Record  Input  Screen 


HOTtilST  Report  Program 
Remove  or  Reactivate  UIC  Records 


Biter  UIC: 


To  Return  to  Menu,  just  press  <RETURN> 


Fig.  46.  UIC  Record  Input  Screen 


HOTLIST  Report  Program 
Remove  or  Reactivate  STATUS  CODE  Records 


Biter  Status  Code:  CL 


To  Return  to  Menu,  just  press  < RETURN) 


That  status  code  is  not  on  the  file 


Press  any  key  to  continue 


Fig.  46.  Status  Code  Record  Not  Found  Screen 


HCTLIST  Report  Program 

Remove  or  Reactivate  ACTION  ACTIVITY  CODE  Records 


Fig.  48.  UIC  Record  Not  Found  Screen 


Fig.  49.  Status  Code  Record  Inactive  Screen 


HCTLIST  Report  Program 
Remove  or  Reactivate  STATUS  CODE  Records 


Status  Code:  CJ 
Leading  Service  (Navy,  Army,  All,  Etc):  All 
Description  of  Status: 

Rejected;  obsolete.  Request  sub  on  new  doc  or  same  item  on  1348-6. 


Code  has  been  reactivated.  Press  any  key  to  continue 


Fig.  50.  Status  Code  Reactivate  Verification  Screen 


HOTLIST  Report  Program 

Remove  or  Reactivate  Action  Activity  Code  Records 


Action  Activity  Code:  NRZ 


Name  of  Action  Activity:  NSC  Charleston 


CODE  IS  CURRENTLY  INACTIVE.  WANT  TO  REACTIVATE?  (Y  or  N)  Y 


Fig.  61.  Action  Activity  Record  Inactive  Screen 


HCTLIST  Report  Program 

Remove  or  Reactivate  Action  Activity  Code  Records 


Action  Activity  Code:  NRZ 


Name  of  Action  Activity:  NSC  Charleston 


Code  has  been  reactivated.  Press  any  key  to  continue 


Fig.  62.  Action  Activity  Reactivate  Verification  Screen 


HCTLIST  Report  Program 
Remove  or  Reactivate  UIC  Records 


UIC:  04720  Name  of  Ship:  USS  CANOPUS 


Type  of  Ship  (SSBN,  SSN,  AS,  etc.):  AS  Hull  Nunber:  34 


UIC  IS  CURRENTLY  INACTIVE.  WANT  TO  REACTIVATE?  (Y  or  N)  Y 


Fig.  63.  UiC  Record  Inactive  Screen 


Fig.  64.  UIC  Reactivate  Verification  Screen 


HOTLIST  Report  Program 
Remove  or  Reactivate  STATUS  COTE  Records 


Status  Code:  CJ 
Leading  Service  (Navy,  Army,  All,  Etc):  All 
Description  of  Status: 

Rejected;  obsolete.  Request  sub  cn  new  doc  or  same  item  on  1348-6. 


CODE  IS  CURRENTLY  ACTIVE.  WANT  TO  REMOVE?  (Y  or  N)  Y 
Are  yen  SURE?  (Y  or  N)  N 

Fig.  56.  Status  Code  Record  Active  Screen 

HOTLIST  Report  Program 
Remove  or  Reactivate  STATUS  CODE  Records 


Status  Code:  CJ 
Leading  Service  (Navy,  Army,  All,  Etc):  All 
Description  of  Status: 

Rejected;  obsolete.  Request  sub  cn  new  doc  or  same  item  cn  1348-6. 


Code  has  been  removed.  Press  any  key  to  continue 


Fig.  66.  Status  Code  Remove  Veriflcat lor.  k, 
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roiUST  Report  Program 
Remove  or  Reactivate  UIC  Records 


Fig.  69.  UIC  Record  Active  Screen 


HOTLIST  Report  Program 
Remove  or  Reactivate  UIC  Records 


UIC:  04720  Name  of  Ship:  USS  CANOPUS 


Type  of  Ship  (SSBN,  SSN,  AS,  etc.):  AS  Hull  tfcnber:  34 


UIC  has  been  removed.  Press  any  key  to  continue 


Fig.  60.  UIC  Remove  Verification  Screen 
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The  flow  chart  shown  in  Figure  61  is  appropriate  for  any  of  these  data 
bases:  STATUS.dbf,  ACTIVITY. dbf,  or  UIC.dbf. 


DATADEL.prg 


Opal  FtlM 
60  TO  Top- 


Translate  Supply  Codes  To  Plain  English 

The  third  option  (from  the  Main  Menu  key  <3>)  performs  a  special  opera¬ 
tion.  Records  for  the  HOTLIST  are  maintained  in  a  file  called  HOTLIST.dbf. 
This  file  includes  data  that  was  input  by  the  user,  as  well  as  piain-English 
translations  of  supply  codes  and  ship  identifications.  It  is  the  RELATE. prg 
module  that  performs  the  actions  of  drawing  information  from  the  STATUS.dbf. 
ACTIVITY. dbf,  and  UIC.dbf  files,  and  translating  those  codes,  as  well  as  pri¬ 
ority  numbers  and  codes,  to  plain-Engiish. 

RELATE. prg  must  be  run  before  printing  any  reports.  Because  of  the 
lengthy  amount  of  time  that  the  translations  may  take,  for  the  convenience 
of  the  user,  the  module  may  be  called  up  from  two  locations  in  the  program. 
Selection  <3>  from  the  Main  Menu  will  place  the  user  into  the  module.  In 
case  the  user  has  forgotten  to  run  the  module  before  going  to  the  Print  mod¬ 
ule,  there  is  another  opportunity  to  run  it  directly  from  the  Print  module. 
Running  this  module  has  not  been  made  automatic,  since  the  user  may  simply 
desire  to  reenter  the  program  and  print  a  report  without  making  changes  to 
the  data  base,  and  the  time  involved  in  running  the  module  would  be  very 
inconvenient,  possibly  deterring  the  user  from  taking  full  advantage  of  the 
program's  capabilities. 

When  the  user  calls  up  the  RELATE. prg  module  from  either  location,  he 
or  she  is  first  provided  with  the  screen  shown  in  Figure  62.  This  screen 
informs  the  user  of  the  module  they  have  entered,  and  provides  the  opportuni¬ 
ty  to  return  to  the  previous  menu  without  running  the  module.  An  entry  of 
<0>,  <ESC>,  or  <RETliRN>  will  return  the  user  to  the  menu  from  which  they 
entered  the  RELATE. prg  module.  An  entry  of  <1>  will  start  the  subprogram. 
No  further  action  is  required  from  the  user  until  the  program  has  finished. 


until  the  subprogram  Is  complete 


When  this  Is  complete,  a  similar  operation  Is  performed  on  the  HOTLIST 
records,  using  a  work  area  consisting  of  the  UIC.dbf  file  and  Its  Indexes.  In 
this  section,  the  program  looks  at  the  enduser  variable  In  each  record,  and 
provides  the  record  with  the  ship's  name,  type,  and  hull  number.  This  takes 
two  passes  through  the  HOTLIST,  as  the  Tender's  own  Jobs  are  Identified 
through  a  different  coding  system  than  those  of  supported  units. 

Finally,  when  all  translations  have  been  made,  the  user  is  provided  with 
the  screen  shown  in  Figure  64.  At  this  point,  a  press  of  any  key  returns  the 
users  to  the  previous  menu. 


HCrTLIST  Report  Program 
Translate  Supply  Codes  to  Plain  English 


All  translations  are  ocspleted  for  all  records. 


Press  any  key  to  return  to  Previous  Menu. 


Fig.  64.  RELATE. prg  Translations  Completed  Screen 
A  flow  chart  of  the  RELATE. prg  module  is  shown  in  Figure  65. 
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Print  Reports 

The  final  module  of  the  HOTLIST  Report  Program  is  the  module  to  Print 
Reports.  A  selection  of  <4>  from  the  Main  Menu  will  move  the  user  into  this 
module,  where  he  or  she  is  given  the  opportunity  to  print  any  of  five  reports. 
The  organization  of  the  module  is  shown  in  Figure  66. 


Fig.  66.  LISTREPS.prg  Organization 

Upon  entry  to  this  module,  the  user  is  presented  with  the  input  screen 
shown  In  Figure  67.  The  user  is  informed  that  the  module  to  translate  supply 
codes  (RELATE. prg)  must  be  run  before  printing  reports.  The  default  entry 
to  this  screen  is  <1>.  so  an  entry  of  <l>.  <ESC>.  or  <RETIJRN>  will  move  the 
user  to  the  RELATE. prg  module.  When  that  module  has  finished  running,  the 
user  will  be  automatically  returned  to  the  screen  in  Figure  67.  A  selection 
of  <0>  from  this  screen  will  return  the  user  to  the  Main  Menu.  A  selection 


of  <2>  will  move  the  user  to  the  menu  screen  shown  in  Figure  68.  It  is  from 
this  menu  that  the  user  may  select  the  report  desired. 


HOTLIST  Report  Program 
Report  Printing  Module 


Ibis  nodule  is  designed  to  automatically  print  reports  that  are 
needed  for  nanagenent  meetings  and  requisition  expediting. 

Before  printing  reports,  you  oust  run  the  'Translate'  nodule 
to  ensure  that  all  information  has  been  added  to  the  records. 

[  1  ]  Translate  Supply  Codes 

[  2  ]  Print  Reports 

[  0  ]  Exit  to  Main  Menu 


Biter  choice  (0-2):  1 


Fig.  67.  LISTREPS.prg  Entry  Screen 


HOTLIST  Report  Program 
Print  Reports 


Select  the  report  you  want  to  print  1 

00  /  OCMD  /  UNITS 

(top-level  information)  I 

Repair  Department 

(sorted  by  work  center)  I 

Expediter 

(sorted  by  action  activity) 

Stock  Check 

(sorted  by  stock  status,  NIIN) 

Inactive  Records 

(sorted  by  stock  status,  NIIN) 

Return  to  Main  Menu  j 

Biter  Choice  (0-5) :  o  | 

Fig.  68.  LISTREPS.prg  Menu  Screen 
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The  choice  of  <1>  from  this  menu  will  generate  the  primary  report:  the 
report  for  the  CO.  Commodore,  tended  units,  and  other  participants  in  REFIT 
management  meetings.  This  report  lists  each  active  requisition,  grouped  by 
tended  unit,  and  subgrouped  within  those  by  priority.  Supply  codes  are  trans¬ 
lated  into  plain  English,  and  each  page  Is  topped  by  a  header  that  includes 
the  date,  page  number,  and  a  list  of  which  fields  are  shown  in  which  locations. 
A  sample  report  is  shown  in  Figure  69. 


Fife  no.  2 


mjnsrnc*  in. 

ACTION  COtWt) 


08/26/87 


Page  no.  1 


unjnsmw  no. 
action  OCtfTOO 
STATUS 
AIMAAKS 


USS  JON  ADAMS  (SSBM  620) 
Priority  Che  Acquisition 


NOT  LIST  Acquisition  Status 
NcrWAXAUM 


stock  m 

njunwr 


BAIL  BEARING 


05062  6291  1A»0 
DISC 

Being  processed  for  direct  delivery  proevireemt ■ 

Oit  for  quote/dlvy.  No  est  contract  aeard  date,  as  of  6338 


05062  63oavni7  TAomrnR 

DCSC 

On  cmtract  for  direct  shijnent. 
DLA700-86-HJU25  ESD  7005 


USS  WX8JA0A  81LCTH  (SSTW  «24) 

Priority  One  Aequlsitims 

05016  622)  V683  STT71  i*l»IEr 

STTC 

On  cmtract  for  direct  shipaent. 

ESD  14  Aiq  87 


OAADi  njMP 


01  190-3)10 

aw  60 


N7T  LIST  Acquisition  Status 
NCtCCATOAE 


01-183-5589 
oil  rt*innt 


08/26/87 

UI 


qn 

JSN 


1 


EA 


1*01-2736 


1  EA 
HWl-0123 


05076  6135-0182  ADATTTR  ASST  00-949-8465 

STCC  15D  PTRISCOTt 

Itna  is  m  backorder  or  leocsewenl  for  direct  delivery. 

Oit  for  ^nte.  Update  15  Apr  87 

05076  6221-11638  STO1  BONNET  01-190-3)10 

DISC  CHU-60 

Rejected;  obsolete.  Acquest  sub  m  nee  dor  or  sane  itna  on  134A-6. 


STOCK  ttIDA  qn 

nqmvnrr  .rai 


UI 


Pad  i  a 

MK  9  HDD  0  ANAI.  8401-5)42 

procurement. 

»AD  1  n 

m  9  WO  0  ANAL  8401-5)42 
(tire  to  ainlication/lD/tecti  data 


1  (A 

NB01-156) 


2  EA 

37)01  728  3 


7KX  VALVE 

3  n 

HP-UK 

17102-1093 

:  scjuiqid 

3  n 

nr  air 

17102-10*1 

-86  ft- 7.1*2. 

Shirrino  by  tnrfc. 

STF7L 

01  84^  5736 

25  n 

Stock. 

11  m 

F7101-3M6 

DC1UW3 

OO  215-8442 

25  DZ 

11  HG 

EA01  0293 

I6-H-5I8).  Air  stiijnmt  erpected 


Fig.  69.  Sample  CO  /  COMO  '  UNIT  Report 


The  Expediter  report  (selection  <3>  from  the  Reports  Menu)  has  a  totally 
different  purpose,  and  thus,  a  different  format.  This  Is  a  listing  of  all  out¬ 
standing  requisitions,  grouped  by  the  Action  Activity  responsible  for  current 
status.  A  sample  Expediter's  Report  Is  shown  in  Figure  71. 


Page  no.  1 

08/26/87 

HOT  LIST  Outstanding  Requisition  List  (by  Action  Activity) 

nun  gry  ui  nomenclature 

UNIT  NO. 

REQUISITION  NO.  TSN 

Action  Activity  Name:  NAVFftC 

01-846-5736  25  Eft  BOLT,  STEEL 

AS 

34 

04720-6355-W165  5623 

Action  Activity  Name:  SPCC 

01-190-3310  2  Eft  STEM  BONNET 

SSBN  624  05076-6223-W683  6453 

00-949-8465  1  EA  ADAPTER  ASSY 

SSBN  624  05076-6135-W182  6243 

1  EA  BALL  VALVE 

SSBN  624  05076-6338-VGA1  1524 

00-949-8465  1  Eft  ADAPT®  ASSY 

0 

05076-6235-W182  7362 

Action  Activity  Name:  NSC  Charleston 

1  EA  CKT  CARD 

SSBN  644  05715-6335-VU4  5243 

3  EA  SELECTOR  VALVE 

AS 

34 

0472O-7024-W637  5362 

3  EA  VALVE  SOLENOID 

AS 

34 

04720-7024-V638  6453 

00-283-4561  1  SH  METAL,  EXPANDED  AS 

34 

04720-7197-1234  4523 

Action  Activity  Name:  DCSC 

1  EA  TACHOMETER 

SSBN  620  05062-6300-W037  0192 

Fig.  71.  Sample  Expediter  Report 
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The  next  report,  much  like  the  expediter's  report.  Is  the  Stock  Check 
Report.  This  report  Is  made  up  of  only  active  requisitions  that  have  stock 
numbers.  The  requisitions  are  broken  Into  the  three  stock  control  groups  of 
reasons  for  non-issue  that  apply  to  stock-numbered  Items:  NC  (not  carried). 
NIS  (not  in  stock),  and  P.IIS  (partlal-not  In  stock).  This  list  assists  the 
expediters  In  checking  outstanding  requirements  against  stock  receipts.  A 
sample  Stock  Check  Report  is  shown  in  Figure  72. 


Page  no.  1 

08/26/87 

HOT  LIST  Outstanding  NUN  List 

NUN 

OH  UI  NCND&A1URE 

UNIT  NO.  REQUISITION  NO.  TSN 

The  following  requisitions  were:  Not  Carried 

00-283-4561 

1  SH  METAL,  EXPANDED  AS  34  04720-7197-1234  4523 

00-949-8465 

1  EA  ADAPTER  ASSY 

0  05076-6235-W182  7362 

01-183-5589 

1  EA  BAIL  BEARING 

SSBN  620  05062-6291-W030  6273 

The  following  requisitions  were:  Not  In  Stock 

00-215-8442 

25  DZ  NOT  LOCKING 

AS  34  04720-9999-V999  6273 

01-190-3310 

2  EA  STEM  BONNET 

SSBN  624  05076-6223-W683  6453 

01-190-3310 

2  EA  STEM  BOWET 

SSBN  624  05076-6223-W638  7823 

The  following  requisitions  were:  Partial  Not  In  Stock 

00-949-8465 

1  EA  ADAPTER  ASSY 

SSBN  624  05076-6135-W182  6243 

01-846-5736 

25  EA  BOLT,  STEEL 

AS  34  0472O-6355-W165  5623 

Fig.  72.  Sample  Stock  Check  Report 
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The  final  type  of  report  is  the  Inactive  Records  List  (selection  <4>  from 
the  Report  Menu).  This  report  Is  designed  to  be  used  in  the  management  of 
the  data  file,  and  in  Identifying  recurring  HOTLIST  parts  for  management  pur¬ 
poses.  This  report  lists  all  inactive  requisitions,  grouped  by  stock  control 
non-issue  code,  and  listed  in  requisition-number  order  within  those  groups. 
A  sample  Inactive  Records  list  is  shown  in  Figure  73. 


Page  no.  1 

08/26/87 

HOT  LIST  Inactive  Records  List 

NUN 

QTi  UI  NCKGCLATURE 

UNIT  ND.  REQUISITION  NO.  TSN 

Reason  for  non-issue  was:  NC 

00-637-4625 

12  FT  ROD 

SSBN  628  05702-7002-V253  7382 

Reason  for  non-issue  was:  NIS 

01-187-6847 

1 

1  EA  VALVE 

SSBN  644  05715-6265- W029  5362 

t 

ft 


m 


.  .•»  , « .  i. » » ■ 


Once  a  selection  has  been  made  of  the  type  of  report  to  print,  the  user 
is  presented  with  the  screen  shown  in  Figure  74.  This  screen  helps  the  user 
ensure  that  the  printer  is  properly  connected  and  set  up  prior  to  attempting 
to  send  files  to  it.  Once  the  user  is  satisfied  that  the  printer  Is  ready,  any 
key  may  be  pressed  to  start  the  print  job. 


Fig.  74.  Printer  Check  Screen 


While  the  printer  is  printing  the  report,  the  screen  shown  in  Figure  76 
is  displayed,  to  prevent  those  in  the  office  from  attempting  to  send  commands 
to  the  computer  before  it  Is  ready  to  receive  them.  Although  only  shown  here 
for  one  of  the  reports,  the  subheading  (the  second  line  at  the  top  of  the 
screen)  changes  to  indicate  the  report  being  printed. 
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HOTLIST  Report  Program 
Print  NI1N  lists  of  Inactive  Requisitions 


Fig.  76.  Report  Printing  Screen 

Flow  charts  of  LISTREPS.prg,  and  the  five  supplementary  programs  (CO- 
RPT.prg  to  print  top  level  reports.  RPRRPT.prg  to.  print  RPPO  reports.  EXP- 
RPT.prg  to  print  expediter  reports,  NIINRPT.prg  to  print  stock  check  reports, 
and  DELRPT.prg  to  print  inactive  requisition  reports)  are  shown  in  Figures 
76  through  81. 
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Fig.  76.  Continued 

1 03 


Open  Data  Base 
sat  variables 


HOTLIST.dbf 
l  HOTB.ndx 


Fig.  79.  EXPRPT  prg  Flow  Chart 


Top  of  Pape? 


Y 


Print  Header 
DELHE  AD.prg 


Throughout  the  HOTLIST  Report  Program,  there  are  repeated  requirements 
to  produce  a  screen  display  for  the  user  to  obtain  Information  or  input  data 
and  query  responses.  In  order  to  reduce  program  operation  lime,  increase 
available  RAM,  and  provide  a  consistent  display  to  make  screen  comprehension 
simpler  for  the  user,  a  subprogram  has  been  included  in  all  screen  display  sec¬ 
tions  of  the  program.  Once  called  up  by  a  program  command,  this  subprogram 
draws  a  border  screen,  and  inputs  the  program  title  and  a  screen  subtitle. 
Command  then  returns  to  the  parent  program,  where  the  center  section  is 
overlaid  with  information,  and  the  small  bottom  section  is  used  for  input 
commands.  A  sample  use  of  this  screen,  is  shown  in  Figure  82. 


Fig.  82.  BORDERS. prg  Screen  With  Sample  Overlay 


Data  input  and  display  screens  are  also  produced  using  subprograms  that 
are  called  up  from  the  module  program.  This  includes  the  data  entry  screens 
shown  in  Figures  15.  20,  25,  and  30,  and  the  remove/replace  verification 
screens  shown  in  Figures  39,  40.  49,  51,  53.  55,  57,  and  59.  Each  of  these 
screens  are  created  by  displaying  the  outline  drawn  by  BORDERS. prg,  and 
overlaying  the  center  section  with  the  information  appropriate  for  that  screen. 
As  an  example,  this  might  include  field  descriptions  combined  with  data  from 
the  record  or  space  for  data  that  goes  in  that  field.  Entry  and  display  screen 
coding  follows  the  appropriate  moduie  program  coding  in  Appendix  A. 

During  production  of  the  reports,  each  new  page  is  started  with  a 
descriptive  header  that  titles  the  page,  states  the  page  number  and  date,  and 
indicates  labels  for  each  field  of  data.  These  headers  are  produced  by  calling 
up  a  subprogram  from  the  report  module  program  whenever  the  page  count 
or  other  criteria  call  for  a  new  page.  The  headers  can  be  seen  in  report 
examples  in  Figures  69  through  73.  Coding  for  these  headers  follows  the 
appropriate  report  printing  module  coding  in  Appendix  A. 


Program  Utilities  and  Operating  Aides 

The  capability  to  automatically  install,  run.  and  remove  the  HOTLIST 
Report  Program  is  included  on  the  program  Master  disk.  These  programs 
assume  that  the  user  has  little  computer  experience  or  understanding,  and 
operate  with  few  commands.  Each  of  these  programs  is  shown  in  Appendix 
A.  The  desk  guide,  shown  in  Appendix  E,  provides  the  user  with  simple 
instructions  for  these  operations. 

Installation.  The  user  is  told  to  Install  dBASE  III  PLUS™  to  a  specific 
directory,  using  directions  from  the  dBASE  manual.  Once  this  has  been  done, 
the  installation  program,  HLINSTAL.bat,  adds  required  commands  to  the  exist- 


ing  AUTOEXEC.bat  and  CONFIG. sys  files  (or  builds  those  files  if  necessary), 
and  sets  aside  a  copy  of  the  old  AUTOEXEC  and  CONFIG  files.  Added  com¬ 
mands  set  a  path  in  the  drive  to  enable  operation  of  required  master  programs 
from  within  other  directories,  and  set  Buffer  and  File  parameters  to  allow 
proper  operation  of  the  program.  The  main  HOTLIST  Report  Program  booting 
program,  HOTLIST.bat,  is  added  to  the  main  directory.  The  installation  pro¬ 
gram  then  creates  a  directory,  and  loads  ail  required  programs,  data  base  files, 
and  index  files  required  for  operation,  to  that  directory.  When  all  installation 
procedures  have  been  completed,  the  user  is  informed,  and  told  to  reboot  the 
computer  to  set  the  new  parameters. 

Operation.  This  program  has  been  written  to  run  from  any  directory  in 
the  C  drive  of  the  computer.  After  typing  "HOTLIST"  from  the  DOS  prompt, 
the  user  is  moved  to  the  appropriate  subdirectory,  and  from  there,  dBASE  III 
PLUS™  is  started,  using  the  MAlNMENU.prg  program.  The  user  sees  the 
dBASE  license  screen,  and  is  moved  directly  to  the  HOTLIST  Introductory 
Screen  (Figure  2).  When  the  user  exits  the  program,  through  either  of  the 
exit  paths  in  the  program,  the  system  control  is  returned  to  the  C  drive  main 
directory. 

Removal.  In  the  event  that  the  user  finds  the  need  to  remove  the  HOT¬ 
LIST  program  and  all  related  files  from  the  computer,  a  utility  program  is 
provided.  This  program  basically  reverses  all  steps  taken  in  the  installation, 
including  replacing  the  AUTOEXEC  and  CONFIG  files  with  the  ones  in  use 
before  the  Installation  was  done.  Three  precautions  have  been  taken  to  ensure 
that  the  user  does  not  run  this  utility  accidentally.  This  program,  as  with 
the  installation  program,  remains  on  the  master  program  disk,  and  is  not 
transferred  to  the  hard  disk.  The  master  disk  is  removed  from  the  computer 


once  installation  is  complete,  so  the  HLREMOVE.bat  program  is  not  easily 
accessible  to  the  user,  and  must  be  deliberately  inserted  and  called  up.  The 
second  and  third  precautions  are  verifications  of  intent  that  are  written  into 
the  program,  informing  the  user  of  the  impact  of  running  the  utility,  and 
requiring  the  user  to  acknowledge  intent  before  the  program  will  operate. 


V.  Conclusions  and  Recommendations 

Conclusions 

This  thesis  began  by  investigating  the  management  and  operational  report 
requirements  of  refit  management  personnel  on-board  FBM  Tenders,  and  deter¬ 
mining  the  feasibility  of  developing  a  microcomputer-based  software  program 
that  would  support  those  requirements.  Literature  research  of  existing  systems 
revealed  specific  and  recurring  requirements,  and  that  a  system  that  would 
easily  produce  a  variety  of  reports  meeting  those  requirements  was  both 
needed  and  feasible. 

The  dBASE  III  PLUS™  software  package  by  Ashton-Tate  was  selected 
as  being  appropriate  for  development  of  this  system  The  required  programs 
and  databases  were  developed  within  the  criteria  identified  as  pertinent  for 
both  management  and  user  needs.  Input  processes  were  matched,  when  pos¬ 
sible,  to  the  processes  used  by  the  SNAP  I  inventory  management  program. 
Operation  of  the  system  is  expected  to  be  performed  by  enlisted  personnel 
ranging  in  rank  from  Seaman  (E-3)  to  First  Class  Petty  Officer  (E-6).  The 
system  was  tested  by  U  S.  Naval  Officers  experienced  in  the  submarine  refit 
and  enlisted  personnel  management  fields.  The  programs  were  then  upgraded 
to  include  recommendations  from  both  the  Naval  Officers  and  AF1T  faculty 
members  knowledgeable  in  the  data  base  programming  arena. 

The  total  system  that  was  developed  can  be  stored  on  one  oV  floppy 
disk  with  a  storage  capacity  of  360  kilobytes,  and  can  be  instalied  on  a  micro¬ 
computer  hard  disk  by  the  user  with  minimum  of  commands.  This  dBASE  Hi 
PLUS™  application  software  will  operate  on  any  PC-compatible  microcomputer 
with  384K  RAM.  one  5V  floppy  drive,  a  hard  disk,  a  monitor  (either  mono¬ 
chrome  or  color),  and  an  80-column  printer  capable  of  using  continuous-form 


paper.  FBM  Tenders  under  the  command  of  PMOLANT  have  been  provided 
with  hardware  of  at  least  this  capability,  and  therefore  can  implement  the 
software  upon  proper  installation  of  dBASE  111  PLUS™  on  those  computers. 

The  system  that  was  developed  will  function  properly  within  the  FBM 
application  for  any  of  the  submarine  tenders  currently  in  service,  including 
the  fast-attack  tenders.  This  is  to  allow  installation  on  a  non-FBM,  or  non- 
Atlantic  Fleet  tender,  should  one  of  the  other  tenders  be  transferred  to  PMO¬ 
LANT  for  FBM  support. 

This  application  could  be  tailored,  with  few  changes,  to  the  needs  or' 
fast-attack  tenders  or  Pacific  Fleet  FBM  tenders,  or  the  needs  of  either  Tri¬ 
dent  Submarine  Refit  Facility.  The  general  processes  used  could,  in  fact,  be 
applied  to  any  systems  which  support  an  organization  who's  mission  it  is  to 
perform  time-limited  job-shop  types  of  maintenance  for  recurring  customers. 

Recommendations 

The  literature  review  surrounding  this  thesis  revealed  a  significant  con¬ 
cern:  the  U.S.  Navy  has  tremendous  unfilled  potential  in  the  area  of  improving 
productivity  and  production  quality  through  the  use  of  microcomputers.  Equip¬ 
ment  has  only  begun  to  be  installed  on  many  of  the  ships,  and  few  applications 
using  readily  available  software  packages  have  been  developed  to  meet  this 
potential.  Although  this  is  largely  due  to  the  high  workloads  of  smpboard 
personnel,  initial  development  of  the  HOTLIST  Report  Program  provides  poten¬ 
tial  for  gains  in  this  area  with  minimal  dedication  of  resources. 

Other  Applications.  The  application  expansion  possibilities  discussed  in 
the  conclusions  section  open  the  door  for  follow-on  systems.  Although  altera¬ 
tions  to  program  software  would  be  required,  potential  candidate  areas  for 


expansion  include,  but  are  not  limited  to  the  following: 


1.  Pacific  Fleet  FBM  Tenders.  Specific  operation  procedures  were  not 
examined  in  this  research,  but  the  mission  similarities  identify  this 
type  of  operation  as  a  prime  candidate  for  easy  system  conversion. 

2.  Fast-Attack  Submarine  Tenders.  The  database  for  these  ships  would 
be  much  larger  than  that  of  the  FBM  Tenders,  and  time  constraints 
are  less  critical,  but  many  other  operational  procedures  are  so  simi¬ 
lar  that  the  end  reports  required  are  almost  identical  (18). 

3.  Navy  Shipyards.  In  this  case,  time  constraints  and  the  job-shop 

repair  functions  closely  resemble  operation  on  an  FBM  Tender. 

Accounting  procedures  vary  from  the  Tenders,  but  most  of  the 
requirements  are  close  enough  to  warrant  implementation. 

4.  Destroyer  Tenders.  Here,  operation  differs  from  FBM  Tenders  even 
more  than  with  fast-attack  submarine  tenders,  but  missions  and  gen¬ 
eral  procedures  are  similar  enough  to  modify  software  for  this  appli¬ 
cation. 

5.  Other  Facilities.  Maintenance  and  repair  facilities  in  other  areas 

of  the  Navy,  and  in  the  other  branches  of  the  DOD  must  also  track 

high  priority  requisitions  critical  to  high-paced  schedules.  The 
commonality  of  requisition  numbers,  stock  numbers,  and  supply 
status  and  action  activity  codes,  provides  an  appropriate  situation 
to  which  this  program  may  be  adapted  with  changes  only  to  organi¬ 
zation  and  work  center  identification  codes. 

Interface  Opportunities.  Many  other  computer  applications  and  systems 
are  being  installed  on-board  these  FBM  Tenders.  Among  the  new  systems, 
there  are  two  that  directly  impact  on  the  HOTLIST  Report  Program,  providing 
opportunities  to  further  reduce  resource  requirements  and  increase  productivity. 
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1.  PMOLANT  HOTLIST.  This  daily  report  is  currently  received  in  a 
computer-readable  format  by  each  of  the  FBM  Tenders.  Develop¬ 
ment  of  direct  input  capabilities  of  that  information  into  the  HOT¬ 
LIST  Report  Program  data  base  would  reduce  input  time  and  errors, 
and  would  significantly  improve  reporting  quality. 

2.  SNAP  I.  This  comprehensive  administrative  system  maintains  infor¬ 
mation  both  on  the  required  stock  item  availability  on-board  the 
Tender,  and  on  the  job  work  center  requirements.  There  is  consid¬ 
erable  information  in  this  system  that  would  enhance  report  quality 
and  ensure  the  highest  level  of  support.  Development  of  interface 
capabilities  with  SNAP  I  for  the  purpose  of  extracting  desired  infor¬ 
mation  would  enhance  the  HOTLIST  Report  Program  s  current  capa¬ 
bilities,  and  provide  opportunities  for  further  improvement. 

Customer  Support.  Many  customer  and  user  needs  have  been  addressed 
and  supported  in  the  development  of  this  system.  There  are  a  few  that 
because  of  dBASE  III  PLUS™,  programmer,  or  time  limitations,  were  not 
included  in  the  programming. 

1.  Archiving.  Although  the  one  tender  currently  using  a  similar  system 
does  not  permanently  remove  records  from  the  database,  a  module 
to  move  selected  records  from  the  main  data  base  to  an  auxiliary 
data  base  would  allow  the  program  to  run  more  smoothly,  without 
losing  the  corporate  Information  contained  in  those  records. 

2.  Data  Analysis.  Records  of  completed  requisitions  provide  an  oppor¬ 
tunity  for  various  types  of  analysis  not  currently  available  on  the 
Tenders.  Such  analysis  might  include  identification  of  stocking 
problems,  either  by  specific  stock  numbers,  or  by  group  and  class 
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of  NSNs.  Graphing  of  high  priority  requirements  by  period  or  bv 
supported  unit  may  reveal  cyclical  or  administrative  problems  that 
can  be  corrected  by  management.  Trend  analysis  can  identify  devel¬ 
oping  management  problems  to  enable  correction  before  they  become 
critical.  These  analysis  functions  may  become  easier  to  implement 
as  improvements  are  made  to  dBASE  and  similar  software. 

3.  Unit  Reporting  Selection.  Presently,  ail  active  requisitions  are 
reported.  A  module  that  provided  the  opportunity  to  select  specific 
supported  units  to  report  would  allow  the  user  to  limit  reports  to 
only  those  units  of  interest  at  any  given  time. 

4.  Other  Upgrades.  Further  research  of  user  requirements  may  reveal 
other  opportunities  to  expand  the  capabilities  of  this  program  to 
other  areas.  This  would  be  especially  valuable  once  the  users  have 
had  some  experience  with  the  program,  and  may  have  expanded 
their  needs  accordingly. 

Implementation.  The  HOTLIST  Report  Program  provides  an  opportunity 
to  the  high-paced,  leanly  staffed  SUBSAT  and  ROVSS  offices  to  produce  a 
required  report  with  much  less  manpower,  while  considerably  lowering  errors. 
The  resulting  product  will  provide  customers  with  a  higher  quality  report  that 
includes  more  information  than  previously  available,  in  more  formats.  Of  even 
more  significance,  the  program  also  provides  the  supply  personnel  with  three 
reports  of  information  previously  unavailable  to  them,  that  will  allow  more 
efficient  management  of  these  critical  requirements,  and  will  provide  oppor¬ 
tunities  to  raise  the  level  of  customer  service  to  new  heights. 
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Appendix  A:  Program  Codint 


STARTUP. PRC 

*  Startup  Modal*  for  IOTLIST  Rpt  Prga  * 


* - sat  ap  talttal  paraaotors 

CLOSE  ALL 

SET  ESCAPE  OPF 

SET  TALE  OFF 

SET  SELL  OFF 

SET  STATUS  OFF 

SET  SEFAOLT  TO  C:\EL 

CLEAR  SETS 

CLEAR  MEMORT 

POSLIC  tltla 

tttla  »  “hotlist  Raport  Prograa’ 
aeerlfy  *  .T. 

DO  WRILE  nverlfy 
stitl*  a  "introduction’ 

MTENOER  a  SPACE(S) 

DO  RORDERS  WITH  tltla.  stitl* 


. 

• 

9-22 

SAY 

s 

S.11 

SAT 

i 

s 

8.  8 

SAT 

s 

9,  S 

SAT 

> 

s 

10,  8 

SAY 

| 

• 

11.  8 

SAT 

• 

12.  a 

SAT 

s 

13,  8 

SAT 

\ 

• 

18.19 

SAT 

2 

s 

18,37 

SAT 

4 

• 

17.28 

SAT 

4 

• 

21.39 

SAT 

• 

s 

2UI 

SAY 

1 

READ 

varsloa  2.1’ 


lapat  critical  "Rot  List”  requisition  data.’ 
a  varlaty  of  raports  for  as*  by  both  those’ 


GET  MTENDCR  PICTURE  ’HMf 


•  - silt  oa  blaak  lapat 

IF  MTEHDER  a  SPACE(S) 

QUIT 

ENOIF 

*  -  check  for  east  coast  taadar 

IF  MTENDERa’OaSIS*  .OR.  MTENDER=’08**8"  .OR.  MTENDER=’04S98’  .OR.: 

MTENOERa-OdTRO’  .OR.  MTENDER*’00891’  .OR.  MTENDERa’20639’  .OR.! 

NTENDERa-MSSS* 

EXIT 

*  -  check  for  ovarsoas  taadar 

ELSE 

IF  NTENDER="0**28"  .OR.  NTENDER  =  ’04829’  .OR.  MTENDER="0e89T" 

EXIT 

»  -  check  for  west  coast  taadar 

ELSE 

IF  NTENDER="20I3Z'  OR.  MTENDER  =  "21118" 

EXIT 

ELSE 

*  22.22  SAY  "Invalid  UIC... Press  <SPACE>  and  Ralapat  UIC’ 

S  23,72  SAY  ” 

WAIT  8PACE140)*” 

LOOP 

ENDIF 

EMDIF 

ENDIF 

avartfpa.F. 

EMDDO 

PURLIC  TENDER 

TENDER  a  MTENOER 

stitl*  a  ’Rights  and  warrantaas" 

DO  RORDERS  WITS  title,  stitl* 

S  9.23  SAY  "***  RESTRICTED  RIGHTS  WARNING  »**" 

t  6.  8  SAY  ’ROTLIST  Raport  Prograa  la  a  copyrighted  package  designed  for  the" 


•  7,  8  SAY  "exclusive  use  of  tbo  United  states  Military,  and  Is  protected  by” 

•  8,  8  SAT  ”U.  s.  Copyright  Law  (Title  17  United  States  Code).  Unauthorized" 

•  8,  8  SAY  'reproduction  and  /  or  sales  aay  result  In  laprlsonaant  of  up  to' 

•  10,  8  SAY  ‘ONE  YEAR,  and  fines  of  up  to  810,000  (17  USC  906).  Copyright' 

8  It,  8  SAY  ‘Infringers  aay  also  be  subject  to  civil  liability.' 

•  12,24  SAY  ****  DISCLAIMER  OF  WARRANTEE  ***' 

•  13,  8  SAY  ‘This  software  and  annual  Is  distributed  wlthont  any  express  or‘ 

•  18.  8  SAT  ‘laplled  warrantees  whatsoever.  Because  of  the  diversity  of  con-' 

8  18,  8  SAY  ‘dltloas  and  hardware  under  which  this  prograa  aay  be  used,  no' 

•  18,  8  SAT  ‘warrantee  of  fitness  for  a  particular  purpose  is  offered.  The" 

•  17,  8  SAY  *aser  Is  advised  to  test  the  prograa  thoroughly  before  relying  on” 

•  18,  8  SAT  ‘it.  The  user  aust  assnae  the  entire  risk  of  using  the  prograa.' 

•  20.27  SAT  "Press  aay  key  to  continue* 

•  22.11  SAY  ‘Copyright  (c)  Claire  C.  Salth  1987.  All  Rights  Reserved* 

•  23. T9  SAY  “ 

WAIT  SPACE(40)*“ 

RETURN 


*************************************** 

*  MAINMENU.PRC  * 

*  aOTLIST  MAIN  MENU  Prograa  * 

*************************************** 

*  — - Introduce  prograa 

DO  STARTUP 

*  - —  Begin  loop  for  aaln  aenu 

DO  WHIL  T. 

*  - Draw  aenu  to  screen 

stltte  =  ‘Main  Mens' 

CROtCE  =  o 

DO  BORDERS  WITH  title,  stltla 


8.27 

SAY 

‘Choose 

Desired  Action" 

8.17 

SAY 

‘f 

1 

j 

Change  or  Add  To  Records  In  a  Data  Base' 

10.17 

SAY 

-( 

2 

i 

Raaove  or  Reactivate  Records  In  a  Data  Base 

12.17 

SAY 

*[ 

3 

i 

Translate  supply  codes  for  reports" 

14.17 

SAY 

't 

4 

i 

Print  Reports" 

18.17 

SAY 

'( 

0 

i 

Exit  the  HOTLIST  Report  Prograa* 

*  - get  user’s  choice 

8  21.24  SAT  ‘Enter  Choice  (0-4):  "  SET  CHOICE  PICT  "9"  RANGE  0.4 
READ 

*  - go  to  subprograa 

DO  CASE 

CASE  CHOICE  =  0 
EXIT 

CASE  CHOICE  =  1 
DO  OATACHC 
CASE  CHOICE  =  2 
DO  DATADEL 
CASE  CHOICE  =  3 
DO  RELATE 
CASE  CHOICE  =  4 
DO  LISTREPS 

ENDCASE 

ENDDO 

*  -  Done  with  prograa.  Clear  all  coaaands  and  return  to  Dot  Prompt. 

SET  TALK  ON 
SET  STAT  ON 
SET  ESCAPE  ON 
CLEAR  SETS 
CLOSE  DATABASES 

*  -  Done  with  prograa.  Exit  to  DOS  proapt. 


QUIT 


*************************************** 

*  BORDERS. PRG  • 

*cl*»r  screen  v  draw  borders  s.  titles  * 
*************************************** 

PARAMETERS  title,  stltle 
CLEA 

•  1.  (TB-LEN<tltla>)/2  SAY  title 

•  3.  <76-LEN(stttle))(2  SAY  Stltle 

•  4.2  TO  4.77 

•  1.1  TO  23. TB  DOUBLE 

•  1M  TO  IB. 77 

RETURN 

*************************************** 

*  DATACHC.PRG  * 

*  Add  To  B  Change  Databases  * 

*************************************** 

DO  WHIL  .T. 

•  - Initialize. clear,  draw  Mean,  a  ask  for  user’s  selection 

CRGCROICE  =  0 

stltle  =  "Change  or  Add  To  Records  In  a  Data  Base" 

DO  BORDERS  MITR  title,  stltle 

•  6.21  SAY  "Select  the  Data  Base  you  want  to  change" 

•  8.26  SAY  *[  1  ]  HOTLIST* 

•  10.26  SAY  "[  2  )  Supply  Status  Codes’ 

6  12.26  SAY  “(  3  )  Action  Activity  Codas" 

6  14.26  SAY  "(  4  ]  U  I  C  S* 

a  16.26  SAY  "[  o  }  Return  to  Main  Menu" 

•  - ask  for  choice 

6  21.26  SAY  "Enter  Choice  (0-4):  "  SET  CRGCBOICE  PICT  "9"  RANGE  0,4 
READ 

•  — - perform  action 

DO  CASE 

CASE  CRGCIOICE  =  0 
EXIT 

CASE  CRGCBOICE  *  1 
DO  ROTCHG 

CASE  CRGCBOICE  =  2 
DO  STATCBG 
CASE  CRGCBOICE  =  3 
DO  ACTTCHG 
CASE  CRGCBOICE  =  4 
DO  UICCIG 
ENDCASE 
ENODO 

RELEASE  ALL 
RETURN 


**************************************** 

*  BOTCBG.PRG  * 

*  Add  To  or  Change  HOTLIST  * 

**************************************** 

*  —  set  up  eovlronaent 

stltle  =  "Change  or  Add  To  Records  In  HOTLIST" 

*  —  open  files 
CLOSE  DATABASES 

USE  ROTLIST  INDEX  R0T8EEK.  ROTB.  ROTC.  BOTE.  HOTCO.  HOTRPR.  BOTEXP 
e  --  mala  loop 
DO  WRILE  .T. 

CLEA 

*  —  get  requisition  date  froa  user 
8T0RE  0  TO  MR9NDATE 

DO  BORDERS  WITR  title,  stltle 

6  6.23  SAT  "Eater  Requisition  Julian  Date:  "  GET  NRONDATE  PICTURE  "9999" 
6  12.21  SAY  "To  return  to  aenu.  lust  press  <RETURN>" 

READ  SAVE 

*  —  exit  on  blank  Input 
IF  MRONOATE  -  0 

EXIT 
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Pf 


•T*  M  * 


ENDIF 

*  —  filter  file  to  only  those  with  requested  requisition  date 
SET  FILTER  TO  RONDATE  =  MRONDATE 

SOTO  TOP 

*  —  get  requisition  serial  nuaber  froa  user 
MSERIAL  =  SPACEU) 

DO  BORDERS  WITB  title,  stltle 

*  8.23  SAY  "Enter  Requisition  Julian  Date:  "  t  LTRIM!STR!MRONDate» 

*  12.17  SAY  "Enter  Four-digit  Requisition  Serial  Nuaber:  "; 

SET  MSERIAL  PICTURE  "!!!9" 

READ 

*  —  look  for  requisition  nuaber  on  file 
ok  *  .T. 

new  =  ,F. 

SEEK  MSERIAL 

*  —  check  whether  or  not  found,  or  If  found,  whether  deleted 
IF  EOFO  .or.  DELETED!)  u  If  true,  will  add  new  record 

IF  DELETED!)  u  record  exists  but  Is  deleted 

•  —  If  DELETED  warn  user  &  ask  whether  to  continue  adding 
aok  =  .F. 

0  14.10  SAY  "This  requisition  nuaber  has  been  deleted  froa 

*  "current  files." 

9  19.22  SAY  "Do  you  want  to  use  It  anyway?  (Y  or  N>" 

9  17.  7  SAY  "WARNING:  Data  presently  in  record  will  be  lost  unless" 
"  record  Is" 

•  18.  8  SAY  "Reactivated  first,  using  ’Remove  or  Replace  Records’": 

♦  "  Module." 

•  21.40  CET  aok  PICTURE  ’Y* 

READ 

IF  .not.  aok  88  If  not  ok.  loop 
LOOP 

ELSE  Ah  If  ok.  prepare  for  add 

*  —  If  user  wants  to  reuse  anyway,  sark  all  associated 

*  transactions  that  are  delated,  then  recall  record 
SEEK  MSERIAL 

REPLACE  DELETECODE  WITB  .T.  WBILE  MSERIAL-SERIAL 
ENDIF 

else  It  otherwise:  no  record  found 

aok  =  .T. 

•  —  verify  addition  of  new  account 

0  14.29  say  "Requisition  Nuaber  not  found." 

•  16.18  SAY  "Do  you  want  to  create  a  new  record?  (Y  or  N)“ 

9  21.40  CET  aok  PICTURE  'Y* 

READ 

IF  .not.  aok  88  If  not  verified,  loop 
LOOP 

ELSE  Mi  otherwise,  create  new  record 

APPEND  BLANK  88  create  new  blank  record 
REPLACE  SERIAL  WITH  MSERIAL.  RONDATE  WITH  MRONDATE 
DELETE  88  aark  deleted  until  verified 

ENDIF 
ENOIF 

»  —  In  either  case  (DELETED  or  EOF)  initialize  variables  to  blank 
STORE  SPACE(68)  TO  MSTATUS.  MRMK 
STORE  SPACE!  19)  TO  MNOMEN.MEQUIP 
STORE  SPACE(ll)  TO  MNIIN 
STORE  SPACEfS)  TO  MENO.  MU1C 
STORE  SPACEI4)  TO  MSTKCTRL.MWKCTR.M  JSN.MTSN 
STORE  SPACE13)  TO  MACTION 
v*  STORE  SPACE !2)  TO  MUI.MSTATCD 
STORE  SPACEtl)  TO  MPRI 
STORE  0  TO  MOTT 
STORE  .T.  TO  MDELCD 
new  =  .T. 

ELSE  88  update  existing  record 

*  —  Initialize  variables  to  values  in  file 
MUIC  =  UIC 
MRONDATE  =  RONDATE 
MSERIAL  =  SERIAL 
MPRI  =  PRIORITY 


i.V«v  <.«■*.*  I 


i.* 


MNOMEN 

=  NOMEN 

MNIIN  = 

NIIN 

MQTY  = 

QTY 

MUI  *  UI 

MEND  = 

ENDUSER 

MSTKCTRL  =  STOCKCNTRL 

MSTATUS 

»  STATUSNAME 

MSTATCD 

=  STATUSCODE 

MACTION 

=  ACTIONACTY 

MEQUIP 

=  EQUIPMENT 

MWKCTR 

=  WORKCENTER 

MJSN  = 

JSN 

MRMK  = 

REMARKS 

MT8N  * 

TSN 

MDELCD 

=  DELETECODE 

EMDIF 

* —  Edit  the  record  until  ok 
■ok  =  .F. 

DO  while  .not.  aok 

*  —  got  data  froa  usar 
DO  HOTIN 

@  21.8  SAY  "Press  <ENTER>  after  entry  tf  cursor  does  not  aove  to 
*  "noxt  Mold." 

8  22.26  SAY  "Press  <ESC>  to  finish  adit." 

READ 

8  21.2  CLEAR  TO  22.77 

*  —  check  for  escape  code.  Break  out  of  loop  If  so. 

»  21.18  SAY  "Is  Input  OK?  <  Y  or  N  )  (  <ESC>  to  QUIT  ) 

SET  Bok  PICTURE  ’Y’ 

READ 

IF  READKEY()=12 
EXIT 
ENDIF 
ENDDO 

IF  Bok  (tit  Bake  change  tf  Input  Is  OK 

REPLACE  UIC  WITH  MUIC,  RQNDATE  WITH  MRQNDATE.  SERIAL  WITH  MSERIAL. 
PRIORITY  WITH  HPRI.  NOMEN  WITH  MNOMEN.  NIIN  WITH  MNIIN.  QTY  WITH: 
MQTY.  DI  WITH  MUI.  ENDDSER  WITH  MEND,  STOCKCNTRL  WITH  MSTKCTRL 
REPLACE  STATUSNAME  WITH  MSTATUS.  STATUSCODE  WITH  MSTATCD. 
ACTIONACTY  WITH  MACTION.  EQUIPMENT  WITH  MEQUIP.  WORKCENTER  WITH: 
MWKCTR.  ISN  WITH  MJSN.  REMARKS  WITH  MRMK.  TSN  WITH  MTSN.S 
DELETECODE  WITH  .F. 


LI.  undelete  record 


tt  end  of  aatn  loop 


RECALL 
ENDIF  aok 
ENDDO  .T. 

REINDEX 

CLEAR 

SET  FILTER  TO 
CLEAR  SETS 
CLOSE  DATABASES 

RETURN 


*************************************** 

*  HOTIN. PRG 

*  HOTLIST  Data  Add/Edlt  Screen  * 

*************************************** 
stttle  =  "Add  or  Update  Requisition  inforaatlon" 

DO  BORDERS  WITH  title,  stltle 

9.  2?  SAT  "Requisition  Inforaatlon" 

7.  6  SaY  "UIC:" 

7,  11  SET  MUIC  PICTURE  "99909” 

7.  19  SAY  "JULIAN  DATE:  "  ♦  LTRIM<STR<MRQNDATE>) 

7.  39  iAY  "SERIAL  •:  "  ♦  MSERIAL 
7.  97  SAY  "NIIN:" 

7.  63  6ET  MNIIN  PICTURE  ”"-!99-9999" 

8.  6  SAY  "PRIORITY  (Use  X  for  sped,  exp.):" 

8,  40  SET  MPRI  PICTURE  "■" 

8.  «9  SAY  "NOMENCLATURE:" 

8  8.  99  GET  MNOMEN  PICTURE  "8‘" 


K 


0 

9. 

6 

SAY 

"OTY:” 

9 

9. 

11 

GET 

NOTY  PICTURE  "99998'' 

9 

9, 

18 

SAY 

“U/I:** 

9 

9. 

23 

GET 

MU1  PICTURE  H!!M 

9 

9. 

27 

SAY 

"ENDUSER:** 

9 

9, 

36 

GET 

MEND  PICTURE  ,*8!“ 

9 

9. 

44 

SAY 

"NIS/PNIS/NC/NS:"* 

9 

9* 

60 

GET 

MSTKCTRL  PICTURE  M" 

9. 

69 

SAY 

“TSN:" 

9, 

70 

GET 

MTSN  PICTURE 

10. 

2 

TO 

to.  77 

11, 

31 

SAY 

“Job  Inforaatlon" 

13. 

6 

SAY 

“JOB  NAME:" 

13. 

16 

GET 

MEOUIP  PICTURE  “0!" 

13, 

39 

SAY 

“WORK  CENTER:** 

13. 

92 

GET 

MWKCTR  PICTURE  "MM" 

13. 

69 

SAY 

"JSN:“ 

9 

13. 

70 

GET 

MJSN  PICTURE  "MM" 

9 

14. 

2 

TO 

14,  77 

9 

19. 

29 

SAY 

"Status  Inforaatlon" 

9 

17. 

13 

SAY 

"STATUS  CODE:" 

9 

t7. 

26 

GET 

MSTATCD  PICTURE  *!•** 

9 

17. 

49 

SAY 

"ACTION  ACTIVITY:** 

9 

17, 

62 

GET 

MACTION  PICTURE  *"«!•** 

9  18.  6  SAY  “REMARKS  (Contract  Number.  ESD.  EOD.  etc.):1' 

9  19,  2  SAY  " 

8  19.  6  GET  MRMK 

9  19,  73  SAY  * 

9  20.  2  TO  20,  77 

RETURN 


********************************»<****** 

*  STATCHG.PRG  * 

*  Change  or  Add  To  STATUS  CODES  * 

*************************************** 

*  —  sat  up  envlronaent 

*  —  open  flits 
CLOSE  DATABASES 

USE  STATUS  INDEX  STATUSC 
title  =  "HOTLIST  Report  Prograa" 

*  —  aala  loop 
DO  WHILE  T. 

CLEA 

*  —  get  status  code  froa  user 
STORE  SPACEI2)  TO  MSTATCD 

stltte  =  "Add  To  or  Change  STATUS  CODES'1 
DO  BORDERS  WITH  title,  stltle 
9  8.30  SAY  ''Enter  Status  Code:  ": 

GET  MSTATCD  PICTURE  "M" 

0  14.21  SAY  "To  return  to  aeou.  Just  press  <RETURN>" 

READ  USAVE 

*  —  exit  on  blank  Input 
IF  MSTATCD  =  SPACE<2) 

EXIT 

ENDIF 

*  —  look  for  status  code  on  file 
ok  =  .T. 

new  =  .F. 

SEEK  MSTATCD 

*  —  check  whether  or  not  found,  or  tf  found,  whether  deleted 
IF  EOF!)  .or.  DELETED!)  LI  If  true,  will  add  new  record 

IF  DELETED!)  LL  record  exists  but  Is  deleted 

•  —  If  DELETED  warn  user  &  ask  whether  to  continue  adding 
aok  *  .F. 

9  14.14  SAY  "This  status  code  has  been  deleted  froa  current  files. 
8  19.21  SAY  “Do  you  want  to  use  It  anyway?  !Y  or  N>" 

•  17.  7  SAY  "WARNING:  Data  presently  In  record  will  be  lost  unless 

♦  “record  Is" 

•  18.  8  SAY  "’Undeleted  first  using  'Delete  or  Undelete  Records’": 


♦  M  Nodule.” 

9  21.40  GET  aok  PICTURE  ’Y' 

READ 

IF  .not.  aok  EE  If  not  ok,  loop 
LOOP 

ELSE  EE  If  ok.  prepare  for  add 

*  —  If  user  wants  to  reuse  anyway,  nark  all  associated 

*  transactions  that  are  deleted,  then  recall  record 
SEEK  MSTATCD 

REPLACE  SDELCD  WITH  .T.  WHILE  HSTATCD=STATUSCODE 
ENDIF 

ELSE  EE  otherwise;  no  record  found 

aok  =  .T. 

•  —  verify  addition  of  new  nccouat 

•  14.21  SAY  ”  Status  code  not  found. 

•  16.18  SAY  "Do  you  want  to  create  a  new  record?  (Y  or  N)“ 

0  21.40  GET  aok  PICTURE  ’Y’ 

READ 

IF  .not.  aok  EE  If  not  verified,  loop 
LOOP 

ELSE  EE  otherwise,  create  new  record 

APPEND  BLANK  EE  create  new  blank  record 
REPLACE  STATUSCODE  WITH  MSTATCD 
DELETE  EE  aark  delated  until  verified 

ENDIF 
ENDIF 

*  —  in  either  case  (DELETED  or  EOF!  Initialize  variables  to  blank 
STORE  SPACE(68)  TO  NSTATUS 

STORE  SPACE14)  TO  MUSER 
STORE  .T.  TO  MSDELCD 
new  =  ,T. 

ELSE  EE  update  existing  record 

*  —  Initialize  verlablea  to  values  In  file 
NSTATUS  =  STATUSNAME 

MUSER  =  USER 
MSDELCD  =  SDELCD 
ENDIF 

* —  Edit  the  record  until  ok 
aok  =  .F. 

DO  WHILE  .not.  aok 

*  —  get  data  froa  user 
DO  STATIN 

9  21.8  SAY  "Press  <ENTER>  after  entry  If  cursor  does  not  move  to  "; 

*  "next  field." 

0  22.26  SAY  "Press  <ESO  to  finish  edit." 

READ 

9  21.2  CLEAR  TO  22.77 

*  —  check  for  escape  code.  Break  out  of  loop  If  so. 

0  21.18  SAY  "Is  Input  OK?  (  Y  or  N  >  (  <ESC>  to  QUIT  )  ": 

GET  mok  PICTURE  'Y' 

READ 

IF  READKEY()  =  12 
EXIT 
ENDIF 
ENDDO 

IF  aok  EE  aake  change  If  Input  Is  OK 

REPLACE  STATUSNAME  WITH  MSTATUS.  USER  WITH  MUSER.  SDELCD  WITH  .F 
RECALL  EE  undelete  record 

ENDIF  aok 

ENDDO  .T.  EE  end  of  aaln  loop 

REINDEX 

CLEAR 

SET  FILTER  TO 
CLEAR  GETS 
CLOSE  DATABASES 
RETURN 


*************************************** 


*  STATIN. PRG  * 

*  STATUS  CODES  Add/Edlt  Screen  * 

*************************************** 
title  =  "■OTtlST  Report  Prograa" 

■title  =  "Add  or  update  Status  codes" 

DO  BORDERS  WITH  title,  stltle 

•  8.  32  SAY  "Status  Code:  "  ♦  STATUSCODE 

•  10.  18  SAY  "Leading  Service  (Navy.  Aray.  All,  Etc):  -. 

SET  MUSER  PICTURE  “!AAA" 

•  12.  S  SAY  "Description  of  Status:" 

•  14.  9  SET  MSTATUS 

RETURN 


****************************************** 

*  ACTYCBG.PRG  * 

*  Add  T*  or  Change  ACTION  activity  CODES  * 
****************************************** 

*  —  set  up  envlronaent 

*  —  open  flies 
CLOSE  DATABASES 

USE  ACTIVITY  INDEX  ACTYB 
title  =  "HOTLIST  Report  Prograa" 

*  --  aaln  loop 
DO  WRILE  .T. 

CLEA 

*  —  get  ectlvlty  code  froa  user 
STORE  SPACE(3>  TO  MACTION 

stltle  =  "Add  To  or  Change  ACTION  activity  cades" 

DO  BORDERS  WITH  title,  stltle 
8  8.24  say  "Enter  Action  Activity  code: 

GET  MACTION  PICTURE  "••!" 

t  14,21  SAY  "To  return  to  aenu.  Just  press  (RETURN)" 

READ 

*  —  exit  on  blank  Input 
IF  MACTION  =  SPACE(3) 

EXIT 

ENDIF 

*  —  look  for  action  activity  code  on  file 
ok  *  .T. 

new  *  .F. 

SEEK  MACTION 

*  —  check  whether  or  not  found,  or  If  found,  whether  deleted 
IF  EOF!)  .or.  DELETED!)  LI  If  true,  will  add  new  record 

IF  DELETED!)  tt  record  exists  but  is  deleted 

•  —  If  DELETED  warn  user  h  ask  whether  to  continue  adding 
aok  =  .F. 

•  14.  9  SAY  "This  Action  Activity  code  has  been  deleted  froa": 

♦  “  current  flies." 

8  19.22  SAY  "Oo  you  want  to  use  It  anyway?  (Y  or  N>~ 

•  17.  7  SAY  "WARNING:  Data  presently  in  record  will  be  lost  unless 

►  "record  Is" 

a  18.  S  SAY  “’Undeleted  first  using  'Delete  or  Undelete  Records'": 

*  “  Module." 

•  21.40  GET  aok  P1CTURF  'Y' 

READ 

IF  .not.  aok  hi  If  not  ok.  loop 
LOOP 

ELSE  It,  If  ok.  prepare  for  add 

*  —  If  user  wants  to  reuse  anyway,  aark  all  associated 

*  transactions  that  ara  deleted,  then  recall  record 
SEEK  MACTION 

REPLACE  ADELCD  WITH  .T.  WHILE  MACTION  =  ACTION  ACTY 
ENDIF 

ELSE  i.1.  otherwise:  no  record  found 

aok  =  .T. 

•  —  verify  addition  of  new  account 

8  14.21  SAY  "  Action  Activity  code  not  found. 

8  18.18  SAY  "Do  you  want  to  create  a  new  record?  (Y  or  N )" 


8  21.40  SET  aok  PICTURE  'V 
READ 

IF  .aat.  aok  It  If  aot  verified,  loop 
LOOP 

ELSE  66  otherwise,  create  new  record 

APPEND  BLANK  66  create  new  blank  record 
REPLACE  ACTIONACTY  WITR  MACTION 
DELETE  lit.  aark  delated  until  verified 
ENDIF 
END1F 

•  —  la  either  case  (DELETED  or  EOF)  Initialize  variables  to  blank 
STORE  SPACE(20)  TO  MACTYNAME 

STORE  .T.  TO  MADELCO 

aew  3  ,t. 

ELSE  KK  update  existing  record 

*  —  initialize  variables  to  values  In  file 
MACTYNAME  *  ACTYNAME 

MADELCD  3  ADELCD 
ENDIF 

* —  Edit  the  record  until  ok 
aok  3  .F. 

DO  WHILE  .net.  aok 

*  --  get  data  froa  user 
DO  ACTY1N 

a  21.8  SAY  "Press  <ENTER>  after  entry  If  cursor  does  not  aove  to 

♦  "next  field." 

a  22.26  SAY  "Press  <ESO  to  finish  edit." 

READ 

a  21.2  CLEAR  TO  22.77 

*  —  check  for  escape  code.  Break  out  of  loop  If  so. 

a  21.18  SAY  "is  Input  0K7  (  Y  or  N  )  (  <ESC>  to  QUIT  ) 

GET  aok  PICTURE  ’Y‘ 

READ 

IF  READKEYO=12 
EXIT 
ENDIF 
ENDDO 

IF  aok  66  aake  change  If  input  Is  OK 

REPLACE  ACTYNAME  WITH  MACTYNAME.  ADELCD  WITR  .F. 

RECALL  66  undelete  record 

ENDIF  aok 

ENDDO  .T.  66  end  of  aaln  loop 

REINDEX 

CLEAR 

SET  FILTER  TO 
CLEAR  GETS 
CLOSE  DATABASES 
RETURN 


*************************************** 
*  ACTYIN.PRG 

♦  ACTION  ACTIVITY  CODES  AddEdlt  Screen* 
*************************************** 
title  =  "HOTLIST  Report  Prograa" 
stltle  3  "Add  or  Update  Action  Activity  Code.;’ 

DO  BORDERS  WITH  title.  Stltle 

8  10.  28  SAY  "Action  Activity  Code;  "  ♦  ACTIONACTY 

a  14.  29  SAY  "Naae  of  Action  Activity;  "  GET  MACTYNAME 

RETURN 


**************************************** 
*  'ICCHG.PRG 

*  Add  To  or  Change  UIC  CODES 

**************************************** 

*  —  set  up  envtronaent.  open  files 
CLOSE  DATABASES 

USE  UIC  INDEX  UICD.  VICE 

♦  —  aaln  loop 


DO  WHILE  .T. 

CLEA 

*  —  get  ulc  f roe  user 
STOKE  SPACE(S)  TO  MUIC 

stltle  =  "Add  To  or  Change  L'ICs" 

DO  BORDERS  WITH  title.  Stltle 

8  8.30  SAT  "Enter  UIC:  *  SET  MUJC  PICTURE  "99999" 

8  14.20  SAT  "To  return  to  aenu.  Just  press  <RETURN>" 

READ 

*  —  exit  on  blank  Input 
IF  MUIC  =  SPACE(S) 

EXIT 

ENDIF 

*  —  look  for  status  code  on  file 
ok  =  .T. 

new  =  .F. 

SEEK  MUIC 

*  —  check  whether  or  not  found,  or  If  found,  whether  deleted 
IF  EOFO  .or.  DELETED!)  11  If  true,  will  add  new  record 

IF  DELETED!)  11  record  exists  but  Is  deleted 

*  —  if  DELETED  warn  user  1  ask  whether  to  continue  adding 
aok  =  .F. 

9  14.18  SAY  "This  UIC  has  been  deleted  froa  current  flies." 

8  13,22  SAY  "Do  you  want  to  use  It  anyway?  iy  or  N>“ 

8  17,  7  SAY  "WARNING:  Data  presently  In  record  will  be  lost  unless 

*  "record  Is" 

8  18.  B  SAY  "’Undeleted*  first  using  ’Delete  or  Undelete  Records’": 

♦  “  Module." 

8  21,40  GET  aok  PICTURE  ’Y’ 

READ 

IF  .not.  aok  11  If  not  ok.  loop 
LOOP 

ELSE  11  If  ok.  prepare  for  add 

*  —  If  user  wants  to  reuse  anyway,  aark  all  associated 

*  transactions  that  are  deleted,  then  recall  record 
SEEK  MUIC 

REPLACE  UDELCD  WITH  .T.  WHILE  MUIC=UIC 
ENDIF 

else  11  otherwise:  no  record  found 

aok  =  ,T. 

*  —  verify  addition  of  new  account 

8  14.18  SAY  "  UIC  not  found. 

8  16.18  SAY  "Do  you  want  to  create  a  new  record?  (Y  or  N>" 

8  21.40  GET  aok  PICTURE  ’Y’ 

READ 

IF  .not.  aok  11  If  not  verified,  loop 
LOOP 

ELSE  11  otherwise,  create  new  record 

APPEND  BLANK  11  create  new  blank  record 
REPLACE  UIC  WITH  MUIC 

DELETE  11  aark  deleted  until  verified 
ENDIF 
ENDIF 

*  —  In  either  case  {DELETED  or  EOF)  Initialize  variables  to  blank 
STORE  SP  ACEI20)  TO  MSHIPNAME 

STORE  SPACE!4)  TO  MSHIPTYPE 
STORE  0  TO  MHULL 
STORE  .T.  TO  MUDELCD 
new  =  .T. 

ELSE  11  update  existing  record 

*  —  Initialize  variables  to  values  in  file 
MSHIPNAME  =  SHIPNAME 

MSHIPTYPE  =  SHIPTYPE 
MHULL  =  HULLNUMBER 
MUDELCD  =  UDELCD 
ENDIF 

Edit  the  record  until  ok 
aok  =  .F. 

DO  WHILE  .not.  aok 

*  —  get  data  froa  user 


*W>5 


DO  UICIN 

9  21.8  SAY  “Press  (ENTER)  after  entry  If  cursor  does  not  aove  to  ": 
♦  “next  field." 

8  22.28  SAY  "Press  <ESC>  to  finish  edit." 

READ 

•  21,2  CLEAR  TO  22.77 

•  —  check  for  encnpe  code.  Break  out  of  loop  If  so. 

•  21,18  SAY  "IS  Input  OR?  <  Y  or  N  )  (  <ESC>  to  QUIT  > 

SET  aok  PICTURE  'V 
READ 

IF  R£ADREY<>=12 
EXIT 
ENDIF 
ENDDO 

IF  aok  48  aako  change  If  Input  Is  ok 

REPLACE  SHPNAMC  WITH  MSRIPNAME,  SIIPTYPE  WJT1  MSBIPTYPE.: 

BULLNUMBER  WITR  MRULL.  UOELCO  WITB  ,F. 

RECALL  44  undelata  record 

ENDIF  aok 

ENDDO  .T.  44  end  of  aala  loop 

REINOEX 

CLEAR 

SET  FILTER  TO 
CLEAR  CETS 
CLOSE  DATABASES 
RETURN 


*************************************** 

*  UICIN. PRC 

*  UIC  Add,  Edit  Screen  ' 

*************************************** 
title  *  -ROTLIST  Report  Prograa" 

•title  *  "Add  or  update  uics" 

DO  BORDERS  WITR  title.  Stltle 

•  8.10  SAY  -UIC:  “  ♦  UIC 

•  8.32  SAY  “Naae  of  Ship:  USS  "  CET  MSRIPNAME  PICTURE  "8!" 

8  12.10  SAY  "Type  of  Ship  (SSBN,  SSN,  AS.  etc.):  -  CET  MSHIPTYPE  PICTURE 
8  12.94  SAY  "Bull  Nuaber:  "  CET  MRULL  PICTURE  "999" 

RETURN 


*************************************** 
*  DATADEL.PRC 

*  Prograa  to  Delete  /  Undelete  Records* 
*************************************** 

DO  WRIL  .T. 

*  - Initialize, clear,  draw  aanu.  4  ask  for  user’s  selection 

DELCROICE  =  0 

stltle  =  "Reaove  end  Reactivate  Data  Base  Records" 

DO  BORDERS  WITB  title,  stltle 


9 

6.18 

say  "Select 

the  Data  Base  you  want 

r» 

4.26 

SAY  "f 

1 

i 

HOTIIST" 

9 

10.26 

SAY  "( 

2 

i 

Supply  Status  Codes" 

9 

12*26 

SAY  “( 

3 

Action  Activity  Codes" 

• 

14.26 

SAY  "[ 

4 

i 

U  1  C  a" 

9 

16,26 

SAY  "f 

0 

j 

Return  to  Main  Menu" 

*  - ask  for  choice 

8  21.28  SAY  "Enter  Choice  (0-4):  "  CET  DELCBOICE  PICT  "9"  RANCE  0.4 

READ 

*  -  perfora  action 

DO  CASE 

CA8E  DELCROICE  =  0 
RETURN 

CASE  DELCBOICE  =  t 
DO  BOTDEL 

CASE  DELCBOICE  =  2 
DO  STATDEL 
CASE  DELCBOICE  =  3 
DO  ACTYDEL 


CASE  OELCIOICE  =  4 
DO  UICOEl 
ENDCASC 
ENDDO 

tELEASE  ALL 
RETURN 


HOTDEL.PRG 

*  Oeiete/Undalete  Record  from  ROTL1ST  * 


*  —  spaa  ftla 
CLOSE  DATABASES 

USE  SOT  LIST  INDEX  IOTSEEK.  IOTB.  IOTC.  ROTE.  ROTCO.  ROTRPR,  ROTEXP 
GOTO  TOP 

stltla*"Roaove  or  Raactlvata  Racorda  froa  hotlist" 

*  —  aala  loop 
DO  WHILE  .T. 

*  —  pat  requisition  data  froa  aaar 
STORE  0  TO  NRONOATE 

DO  BORDERS  WITH  tttls.  Stltla 

*  6.10  SAY  "Enter  Requisition  Julian  Dalai"  GET  KRQNDATE  PICTURE  "IW 

P  10.10  say  "To  Ratarn  to  Mann.  Juat  press  <return>“ 

READ  SAVE 

*  —  axlt  on  blank  Input 
IF  NRONOATE  a  0 

EXIT 

ENDIF 

*  —  flltar  ftla  to  only  thoaa  with  requested  requisition  data 
SET  FILTER  TO  RONDATE  =  NRONOATE 

*  —  gat  aarlal  aaabar  froa  usor 
NSERIAL  *  SPACEI4) 

DO  BORDERS  WITH  tltla.  stltla 

O  6.10  SAY  "Eatar  Requisition  Julian  Data:  "  ♦  LTRINISTRtN  ROND  ATE)) 

0  10,10  SAY  "Eatar  Four-digit  Raqulaltlon  Serial  Nuabar: 

GET  NSERIAL  PICTURE  "!!!«“ 

READ 

a  —  look  for  aarlal  nuabar  on  flla.  If  not  on  Ilia,  loop  back  to  start 
SEER  NSERIAL 

IF  EOF!)  66  not  on  flla 

aok  =  "  “ 

a  14.10  SAY  “That  raqulaltlon  nuabar  la  not  on  tbe  BOTLIST" 

•  21.27  SAY  "Prasa  any  key  to  continue"  GET  aok 

READ 

LOOP 


ENDIF 

*  —  display  racord 
DO  HOTSROW 

•  —  display  delated/undeletad  status 

IF  DELETED!)  66lf  record  Is  deleted,  ask  If  wauled  to  recall 

ok  =  T. 


9  21.13  SAY  "RECORD  IS  "URRENTLY  INACTIVE.  WANT  TO  RE  ACTIV  ATE-’": 
♦  "  <Y  or  N )"  GET  ok  PICTURE  "Y" 


READ 
IF  Ok 

RECALL 

aok  =  "  " 

0  21.12  SAY  "Record  has  bean  reactivated.  Press  any  key  to  ' 
♦  "continue  "  GET  mok 

READ 
ENDIF  ok 

•  21.2  CLEAR  TO  22,77 

ELSE  66  aot  deleted:  ask  If  wBDt  to  delete,  tbsn  verify 

aok  -  .F. 

0  21.13  SAY  "RECORD  IS  CURRENTLY  ACTIVE.  WANT  TO  REMOVE?  (Y  or  N>": 
GET  aok  PICTURE  "T" 

READ 
IF  aok 

ok  -  .F. 
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9  22.30  SAY  "Are  you  SURE?  (Y  or  N>"  CET  ok  PICTURE  “Y" 

READ 

•  21.2  CLEAR  TO  22.T7 
IF  Ok 

DELETE 

ok  =  “  " 

•  21.12  SAY  "Record  has  been  reaoved.  Press  any  key  to  “: 
♦  "continue"  GET  ok 

READ 
ENDIF  ok 
ENDIF  aok 
ENDIF  DELETED!) 

ENDDO 

CLEAR 

CLOSE  DATABASES 
RETURN 


*************************************** 
*  HOTSIOW.PRG 

*  HOTLIST  Oelete/Undelete  screen  » 

*************************************** 
stltle  =  "Reaove  or  Reactivate  BOTLIST  Records" 

DO  BORDERS  HITS  title,  stltle 


9.  27 

SAT 

"Requisition  Inforaatlon" 

T.  6 

SAY 

"UIC:  "  ♦  UK 

7.  19 

SAY 

"JULIAN  DATE:  “  ♦  LTRIM<STR(MRQNDATE>> 

7.  39 

SAY 

"SERIAL  9:  “  ♦  MSERIAL 

7.  37 

SAY 

"NUN:  "  ♦  NUN 

B.  • 

SAY 

"PRIORITY  (Use  X  for  sped,  exp.):  "  ♦  PRIORITY 

8.  49 

SAY 

"NOMENCLATURE:  "  ♦  NOMEN 

9.  • 

SAY 

"OTY:  "  ♦  LTRIMISTR(QTY)) 

9.  18 

SAY 

“U/t:  "  *  ui 

9.  27 

SAY 

"ENDUSER:  "  »  ENDUSER 

9.  44 

SAY 

"NIS/PNIS/NC/NS:  "  ♦  STOCKCNTRL 

9.  BO 

SAY 

"T8N:  "  ♦  TSN 

10.  2 

TO 

10.  77 

11.  31 

SAY 

"Job  inforaatlon" 

13.  B 

SAY 

"JOB  NAME:  ■  ♦  EQUIPMENT 

13.  39 

SAY 

"WORN  CENTER:  "  ♦  WORKCENTER 

13.  BS 

SAY 

"JSN:  ”  ♦  JSN 

14.  2 

YO 

14.  77 

19.  29 

SAY 

"Status  inforaatlon" 

17.  13 

SAY 

"STATUS  COOE:  "  ♦  STATUSCODE 

17,  40 

SAY 

"ACTION  ACTIVITY:  "  *  ACTIONACTY 

18.  B 

SAY 

"REMARKS  (Contract  Nuaber.  ESD.  EDO.  etc.):" 

19.  2 

SAY 

“  ” 

19.  6 

SAY 

REMARKS 

19.  73 

SAY 

•  20.  2 

RETURN 

TO 

20.  77 

* 


STATDEL.PRG  » 

*  Delete/Undelete  STATUS  CODES  * 


I 


f 

f 

f 

i 


r 


*  --  open  file 
CLOSE  DATABASES 

USE  STATUS  INDEX  STATU6C 
GOTO  TOP 

stltle«"Rnaov*  or  Reactivate  STATUS  CODE  Records" 

*  --  aala  loop 
DO  WHILE  .T. 

*  —  get  status  code  froa  nser 
STORE  SPACEI2)  TO  MSTATUS 

DO  BORDERS  WITH  title,  stltle 

B  S.IO  SAY  "Enter  Status  Code:"  CET  MSTATUS  PICTURE  “!!" 

•  10.10  SAY  “To  Return  to  Menu,  lust  press  <RETURN>" 

READ 
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*  —  exit  an  blank  Input 
IF  MSTATUS  =  SPACEI2) 

EXIT 

ENDIF 

*  —  look  Tor  atatun  coda  on  file.  If  not  on  file,  loop  back  to  start 
SEEK  MSTATUS 

IF  EOFO  LI  not  on  file 

■ok  *  "  " 

•  14.10  SAY  “That  status  code  la  not  on  the  file" 

•  21.27  SAT  "Press  any  key  to  continue1'  SET  aok 
BEAD 

LOOP 

ENDIF 

*  —  dlaplay  record 
DO  STATSROW 

*  —  display  deleted/undeleted  status 

ir  DELETED!)  uif  record  Is  deleted,  ask  if  wanted  to  recall 
ok  *  .T. 

•  21.12  SAY  "CODE  IS  CURRENTLY  INACTIVE.  WANT  TO  REACTIVATE?": 

•  '  (Y  or  N)“  GET  ok  PICTURE  ”T” 

READ 
IF  Ok 

RECALL 

■Ok  =  "  “ 

•  21.2  CLEAR  TO  22.77 

•  21.13  SAY  "Code  has  been  reactivated.  Press  any  key  to 

♦  "continue"  SET  aok 

READ 
ENDIF  ok 

•  21.2  CLEAR  TO  22.77 

ELSE  IS  not  deleted:  ask  If  want  to  delete,  then  verify 

aok  *  .F. 

•  21.13  SAY  "COOE  18  CURRENTLY  ACTIVE.  WANT  TO  REMOVE?  (Y  or  N)" 

SET  aok  PICTURE  "Y" 

READ 
IF  aok 

ok  =  .F. 

•  22.30  SAY  "Are  you  SURE?  (Y  or  N>"  SET  ok  PICTURE  "Y" 

READ 

•  21.2  CLEAR  TO  22.77 
IF  ok 

DELETE 

ok  =  "  “ 

•  21.13  SAY  “Code  has  been  reaovad.  Press  any  key  to 

♦  "continue"  SET  ok 

READ 
ENDIF  ok 
ENDIF  aok 
ENDIF  DELETED!) 

ENDDO 


CLEAR 

CLOSE  DATABASES 
RETURN 


*************************************** 


STATSBOW.PRS 

STATUS  CODES  Display  screen 


title  *  "HOTLIST  Report  Prooraa" 

stltle  =  "Reaove  or  Reactivate  STATUS  CODE  Records" 
DO  BORDERS  WITH  title,  stltle 

•  B.  32  SAY  "Status  Cods:  "  ♦  STATUSCODE 

•  10.  9  SAY  "Leading  Service  INavy.  Aray.  All,  Etc): 

0  12.  22  SAY  "Description  of  Statua:" 

9  M.  9  SAY  STATUSNAME 


*************************************** 


*  ACTYDEL.PRG  * 

* Delete/Und elate  ACTION  ACTIVITY  COOES* 

*************************************** 

*  —  op«n  file 
CLOSE  DATABASES 
OSE  ACTIVITY  INDEX  ACTYB 
GOTO  TOP 

stltle=“Reaove  or  Reactivate  ACTION  ACTIVITY  CODE  Records'* 

*  —  aala  loop 

DO  WBILE  .T. 

*  —  gat  status  coda  froa  user 
STORE  SPACE13)  TO  MACTION 
DO  BORDERS  WITR  title,  stltla 

*  *,10  SAY  “Eater  Action  Activity  Coda:“  GET  MACTION  PICTURE  "!!!“ 

*  10.10  SAY  “To  Return  to  Menu,  just  press  <RETURN>“ 

READ 

*  —  exit  on  blank  Input 
IF  MACTION  =  SPACE13) 

EXIT 

ENDIF 

*  —  look  for  status  code  on  file.  If  not  on  file,  loop  back  to  start 
SEEK  MACTION 

IF  EOFO  kk  not  on  file 

aok  *  »  “ 

•  M.io  SAY  “That  action  activity  code  Is  not  on  the  flle“ 

0  21.27  SAY  “Press  any  key  to  cont!nue“  GET  aok 
READ 
LOOP 

ENDIF 

*  —  display  record 
DO  ACTYSBOW 

*  —  display  deleted/undeleted  status 

IF  DELETED!)  Ulf  record  Is  deleted,  ask  If  wanted  to  recall 
ok  =  .T. 

•  21.12  SAY  "CODE  IS  CURRENTLY  INACTIVE.  WANT  TO  REACTIVATE?": 

•  “  (Y  or  N)“  GET  ok  PICTURE  "Y" 

READ 
IF  ok 

RECALL  . 

aok  *  “  "  | 

•  21.2  CLEAR  TO  22.77 

•  21.13  SAY  “Code  has  been  reactivated.  Press  any  key  to 

*  “continue"  GET  aok 

READ 
ENDIF  ok 

•  21.2  CLEAR  TO  22.77 

ELSE  kk  not  deleted:  ask  If  want  to  delete,  then  verify 

aok  *  F. 

•  21.13  SAY  "CODE  IS  CURRENTLY  ACTIVE.  WANT  TO  REMOVE?  (Y  or  N)“: 

GET  aok  PICTURE  “Y" 

READ 
IF  aok 

ok  =  .F. 

•  22.30  SAY  "Are  you  SURE?  (Y  or  N>"  GET  ok  PICTURE  "Y" 

READ 

•  21.2  CLEAR  TO  22.77 
IF  ok 

DELETE 
ok  =  “  “ 

•  21.13  SAY  "Code  has  been  reaoved.  Press  any  key  to  ": 

♦  "continue"  GET  ok 

READ 
ENDIF  ok 
ENDIF  aok 
ENDIF  DELETED!) 

ENDDO 
CLEAR 

CLOSE  DATABASES 

RETURN 
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*  actysbow.prc  * 

*  ACTION  ACTIVITY  CODE  Display  Scraan  * 


tltla  «  ’BOTLIST  (apart  Prograa’ 

atltla  =  "(eaova  or  Reactivate  Actlaa  Activity  Coda  Records’ 
00  BOBBERS  WIT!  tltla,  stltla 

•  10.  M  SAY  ’Action  Activity  Coda:  "  ♦  ACTIONACTY 

D  14.  29  SAT  **M«  Of  Action  Activity:  "  ♦  ACTYNAME 

RETURN 


*************************************** 

*  UICDEL.PRC  * 

»  Delete/uadelete  Uics  * 

******* ** *******  ****** ** ********* ****** 

*  —  opaa  flla 
CLOSE  DATABASES 

USE  UIC  INDEX  UICD.  UICE 
C0T0  TOP 

stltle="Reaove  or  Raactlvate  UIC  Records" 

*  —  aaln  loop 
DO  WBILE  .T. 

*  —  gat  status  coda  froa  user 
STORE  SPACE(S)  TO  MUIC 

DO  BORDERS  WITS  title.  Stltle 

*  8.30  SAT  “Eater  UIC:“  GET  MUIC  PICTURE  "WM9" 

S  14.20  SAY  “To  Return  to  Menu,  just  press  <RETURN>“ 

READ 

*  —  exit  oa  blank  Input 
IF  MUIC  =  SPACE  (9) 

EXIT 

ENOIF 

*  —  look  for  ulc  on  flla.  If  not  on  flla.  loop  back  to  start 
SEES  MUIC 

IF  EOF!)  &S  not  on  file 

aok  =  "  " 

0  14.10  SAY  ’That  UIC  la  not  on  the  file* 

0  21.27  SAY  ’Press  any  key  to  continue*  SET  aok 

READ 

LOOP 

ENDIF 

»  —  display  record 
DO  UICSBOW 

*  —  display  deleted/undeleted  status 

IF  DELETED!)  lllf  record  Is  deleted,  ask  If  wanted  to  recall 
ok  =  T. 

0  21.13  SAY  "UIC  IS  CURRENTLY  INACTIVE.  WANT  TO  REACTIVATE?’: 

•  ’  <Y  or  N)"  GET  Ok  PICTURE  "Y" 

READ 
IF  ok 

RECALL 
aok  =  '  “ 

9  21.2  CLEAR  TO  22. T7 

9  21.13  SAY  "UIC  has  been  reactivated.  Press  any  kev  to  “! 

♦  ’continue’  GET  aok 

READ 
ENDIF  ok 

•  21,2  CLEAR  TO  22.77 

ELSE  EL  not  deleted:  ask  If  want  to  delete,  than  verify 

aok  *  .F. 

•  21.13  SAY  "UIC  IS  CURRENTLY  ACTIVE.  WANT  TO  REMOVE’  (Y  or  N>“: 

CET  aok  PICTURE  ’Y* 

READ 
IF  aok 

ok  =  F. 

•  22.30  SAY  “Are  you  SURE?  (Y  or  N>"  CET  ok  PICTURE  "Y" 

READ 

•  21.2  CLEAR  TO  22.77 
IF  ok 
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DELETE 

ok  *  “  “ 

•  21.13  SAY  "UIC  has  baas  removed.  Prasa  any  kay  to 
♦  "continue"  SET  ok 

READ 
ENDIF  ok 
EN01F  aok 
ENDIF  DELETED!) 

ENDDO 

CLEAR 

CLOSE  DATABASES 
RETURN 


a  UICSIOW.PRG  * 

*  UIC  Display  Scraan  * 

*************************************** 

stltla  =  'Remove  or  Raactlvata  UIC  Records' 

DO  BORDERS  WITB  tltla.  stltla 
9  a.  10  SAY  “UIC:  "  .  UIC 

8  8.  32  SAY  "Naaa  of  Ship:  USS  “  ♦  SHIPNAME 

B  12.  10  SAY  “Typa  of  Ship  (SSBN.  SSN.  AS.  etc.):  “  ♦  SIIPTYPE 
8  12.  94  SAY  “Bull  Number:  *  ♦  LTRIMISTRIHULLN  UMBER)) 

RETURN 


*************************************** 

*  RELATE. PRC  * 

*ralata  HOTLIST.DBF  to  other  databases* 
*************************************** 


CLOSE  DATABASES 


*  - -  clear  screen  and  iafora  user  of  purpose  of  aodula 

stltla  *  “Translate  Supply  codas  to  Plain  English' 

OCBOICE  =  0 

DO  BORDERS  WITB  tltla.  stltla 

B  8. IB  say  “This  choice  will  translate  all  supply  codas' 
a  8,18  say  “(such  as  status  and  action  activity  codes)* 

B  10,10  SAY  “to  plain  English  for  Input  to  aanageaent  and  ROTLIST  reports' 

B  12.27  SAY  “Choose  Desired  Actloo’ 

B  14.20  SAY  *J  1  1  Prepare  Database  for  Reports" 

B  18.20  SAY  “l  0  )  Return  to  Previous  Menu' 

B  21.29  SAY  'Enter  Choice  (0  or  1):  '  GET  QCHOICE  PICT  '9"  RANGE  0.1 

READ 

*  - If  return  requested,  return  to  main  menu 

IF  OCBOICE  =  0 

RETURN 


ELSE 

DO  BORDERS  WITB  title,  stttle 
B  8.9  SAY  "*  *  ** 

B  10,9  SAY  "*  *  *  * 

B  11.10  SAY  '*  *  * 

8  12.10  SAY  '*  *  *  * 

9  13.11  SAY  "**  **  *  * 

<*  14.11  SAY  ”*  *  ** 

8  21,  32  SAY  'Please  Stand  By' 

* - Identify  work  areas 


***** 

*  * 
*  * 

***** 

*  * 

*  * 


*  * 
*  * 

A  * 

*  *  A 
*  * 


* 

* 

A 


*  * 

A  A  * 

A  A  A 
*  *  * 

*  *  A 

*  * 


A  *AM 


*  *  A  *  M 

A  * 

AAA" 


SELECT  A 

USE  IOTLIST  INDEX  80TB.  HOTSEEK.  HOTC.  ROTE.  HOTCO.  HOTRPR.  IOTEXP 

* - —  laser!  action  activity  nones  and  priority  naaes 

SELECT  B 

USE  ACTIVITY  INDEX  ACT  YB 
SELE  A 
GOTO  TOP 

DO  WIILE  .NOT.  EOF!) 

SELE  B 

SEEK  A->ACTI0N  ACT  Y 

REPLACE  NEXT  I  A->ACTYNAME  WITH  B->ACT YN AME 
SELE  A 

IF  PRIORITY  =  **  1  ’* 
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REPLACE  A->PRIN  AME  WITH  "One" 

ELSE 

IF  PRIORITY="X" 

REPLACE  A->PRINAME  WITH  "Special  Expedite" 

ELSE 

IF  PRIORI!  Y="N" 

REPLACE  A->PRINAME  WITH  "Four" 

ELSE 

IF  PRIOR!TY  =  "2" 

REPLACE  A->PRINAM£  WITR  "Two” 

ELSE 

IF  PRIORITY  =  ”S" 

REPLACE  A-EPRINAME  WITH  "Five" 

ELSE 

REPLACE  A->PRINAME  WITH  "(Other)" 

ENOIF 

ENDIF 

EMDIF 

ENDIF 

ENOIF 

IF  STOCKCNTRL="NS" 

REPLACE  A->WHY  WITH  "Non-Standard  Requisition" 

ELSE 

IF  STOCKCNTRL="NIS" 

REPLACE  A->WHY  WITH  "Not  IB  Stock" 

ELSE 

IF  STOCKCNTRL="NC“ 

REPLACE  A— >WH Y  WITH  “Not  Carried" 

ELSE 

IF  STOCKCNTRL="PNIS“ 

REPLACE  A->WHY  WITH  "Partial  Not  in  Stock" 

ELSE 

REPLACE  A— >why  WITH  ‘Unknown  Reason" 

ENDIF 

ENDIF 

ENDIF 

ENDIF 

SKIP 

ENODO 

*  — — -  insert  status  code  descriptions 
SELECT  C 

USE  STATUS  INDEX  STATUSC 
SELE  A 

SET  INDEX  TO  HOTC.  HOTB.  HOTSEEK.  BOTE.  HOTCO.  HOTRPR.  HOTEXP 
GOTO  TOP 

DO  WHILE  .NOT.  EOF ( ) 

SELE  C 

SEEK  A->STATUSCOOE 

REPLACE  NEXT  l  A->ST  ATUSN  AME  WITH  C->ST  AT1JSN  AME 
SELE  A 
SKIP 
ENDDO 

CLOSE  DATABASES 

*  - Insert  ship  naaes  for  own  tender 

SELECT  D 

USE  UIC  INDEX  UICD.  UICE 
SELE  A 

USE  HOTLIST  INDEX  HOTE.  HOTC.  HOTB.  HOTSEEK.  HOTCO.  HOTRPR.  HOTEXP 
GOTO  TOP 

DO  WHILE  .NOT.  EOFO 
IF  ASC(ENDUSER)  >  37 
SELE  D 

SEER  TENDER  M,A->UIC 

REPLACE  NEXT  1  A->SH!PNAME  WITH  0->SHIPNAME.  A->BULLNUMBER  WITH  : 

D->RULLNUMBFR.  A->SHIPTYPE  WITH  0->SB!PTYPE 
SELE  A 
ENOIF 

SKIP 

ENDDO 

*  -  Insert  ship  naaes  for  other  vessels 


wOTim uvuv  m  ut  > v*  rwor*»v*y*ir»n.y  ■*  "V  'j wy  *  J  W V W\W.*WJWUW '  '\V- 


SELECT  0 

SET  INDEX  TO  UICE.  UICD 
SELE  A 

SET  INDEX  TO  BOTE,  HOTC,  HOTB.  HOTSEEK.  BOTCO.  ROTRPR.  BOTEXP 
GOTO  TOP 

00  WHILE  .NOT.  EOFO 
IF  ASC(ENDUSER)  <  98 
SELE  D 

SEEK  VAL(A->£NDUSER> 

REPLACE  NEXT  1  A->SHIPNAME  WITH  D->SHIPNAME,  A->HULLNUMBER  WITH  : 

D->HULL  NUMBER.  A->SHIPTYPE  WITH  D->SBIPTYPE 
SELE  A 
ENDIF 

SKIP 

ENDDO 

** 

ENDIF 

CLOSE  DATABASES 
DO  BORDERS  WITK  tltle.stltle 

•  10.16  SAY  "All  translations  are  completed  for  all  records." 

0  21.21  SAY  “Press  any  key  to  return  to  Previous  Menu." 

0  23. T9  SAY  "“ 

WAIT  SPACE(90>*"" 

RETURN 


*************************************** 

*  LISTREPS.PRG  * 

*  prograa  to  aalect  and  print  reports  * 
*************************************** 

DO  WHILE  T. 

•  - -  describe  aodnle,  realnd  user  to  do  relate,  dive  chance  to  exit 

PCIOICE  =  1 

00  WHILE  PCHOICE  =  1 

stttle  *  "Report  Printing  Module" 

DO  BORDERS  WITH  title,  stltle 

•  6.  8  SAY  "This  aodnle  Is  designed  to  autoaatlcally  print  reports  that  are” 

8  7.10  SAY  "needed  for  aaaageaent  aeetlngs  and  requisition  expediting.” 

9  9.  9  SAY  "Before  printing  reports,  yon  aust  run  the  ’Translate’  aodule" 

•  10.  9  SAY  “to  ensure  that  all  lnforaatlon  has  been  added  to  the  records." 

8  12.29  SAY  “l  l  ]  Translate  Supply  Codes" 

8  19.29  SAY  "[  2  J  Print  Reports" 

8  16.29  SAY  "[  0  ]  Exit  to  Main  Menu" 

8  21.26  SAY  "Enter  choice  (0-2):  "  GET  PCHOICE  PICT  ”9"  RANGE  0.2 
READ 

IF  PCHOICE  =  0 
EXIT 
ELSE 

IF  PCHOICE  =  1 
DO  RELATE 

ENDIF 

ENDIF 

ENDDO 

IF  PCHOICE  =  0 
RETURN 

ENDIF 

•  - clear  screen  6  ask  for  user’s  selection 

stltle  =  "Print  Reports" 

RPTCHOICE  =  0 

DO  BORDERS  WITH  title,  Stltle 
» - draw  aenu  to  screen 

8  6,29  SAY  "Select  the  report  you  want  to  print" 

8  8.12  SAY  "f  1  J  CO  /  COMO  /  UNITS" 

8  8.38  SAT  "(top-level  lnforaatlon)" 

8  10.12  SAY  "(  2  1  Repair  Departaent" 

8  10.38  SAY  "(sorted  by  work  center)” 

8  12.12  SAY  “(  3  )  Expediter" 

8  12.38  SAY  "(sorted  by  action  activity)" 

8  19.12  SAY  "J  9  )  Slock  check" 

8  19,38  SAY  "(sorted  by  stock  status.  NUN)" 
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9 

16,12 

SAY 

"f  9  ) 

Inactive 

Records" 

9 

16*38 

SAY 

“(sorted 

by  stock 

status.  NIIN)~ 

9 

18.12 

SAY 

"[  0  ] 

Return 

to  Main  Menu" 

*  -  ask  for  choice 

9  21.27  SAY  “Enter  Choice  (0-9):  "  GET  RPTCHOICE  PICT  "9“  RANGE  0.9 

READ 

IF  RPTCBOICE  =  0 
RETURN 

ENOIF 

atltle  =  “Printer  Check" 

DO  BORDERS  WITS  title,  stltle 

■  8.14  SAY  “Please  check  to  make  sure  that  your  Printer  Is  ready" 

H  12.16  SAY  "Please  aake  sure  that  your  printer  Is  turned  on," 

*  14.14  SAY  "and  contlnuous-fora  paper  Is  at  the  top  of  the  fora." 
e  21.27  SAY  "Press  any  key  when  ready." 

0  23,79  SAY  "" 

WAIT  SPACE(40)  +  “" 

*  - go  to  appropriate  report  control  screen 

DO  CASE 


CASE  RPTCHOICE 
DO  CORPT 
CASE  RPTCBOICE 
DO  RPRRPT 
CASE  RPTCBOICE 
DO  EXPRPT 
CASE  RPTCBOICE 
DO  NIINRPT 
CASE  RPTCHOICE 
DO  DELRPT 

ENDCASE 

ENDDO 

RETURN 


=  1 


=  4 


*************************************** 

*  CORPT. PRG  * 

*  print  reports  for  CO/CONO/UNITS  * 
*************************************** 

SET  DEVICE  TO  SCREEN 

stltle="Prlot  Reports  for  CO/COMO/UNITS" 

DO  BORDERS  WITH  title,  stltle 

0  9,  9  SAY  "*****  *****  *  *  *  *******  *  *  * 

0  10.  9  SAY  "*  *  *  *****  *  *  **  * 

0  11.  9  SAY  "*  **  *****  *  *  *  *  * 

0  12.  9  SAY  "*****  *****  ****  *  **** 

@  13.  9  SAY  ■'*  ******  *  *  *  ** 

0  14.  9  SAY  "*  *****  *  *** 

0  21,32  SAY  "Please  Stand  By" 

SET  DELETED  ON 

USE  HOTLIST  INDEX  HOTCO 

*  -  Initialize  variables 

adate=date<) 

pageno-0 

pagelen-62 

cntr=0 

aargln-o 

svalue=IIF(ulc  =  ’  ') 

ssvalue=IIF(prlorlty  =  ’  ’> 

SET  DEVICE  TO  PRINT 

*  -  loop  to  print  reports 

DO  WHILE  .NOT.  EOFO 

*  -  lop  of  page  processing 

IF  cntr=0 

DO  COBLAD  with  cntr.adate.pageno 

ENDIF 

*  -  print  new  boat  If  neccessary 

IF  svaluefulc  or.  cntr=ll  IS  If  new  uic 

coir=cntr *2 
IF  cstr>pagelen-6 

DO  COHEAD  with  cntr.adate.pageno 


***" 

*' 

****■’ 


1.17 


ENDIF 

9  cntr.  aargln  SAY  "USS  “  ♦  TRIM(SHIPNAME)  ♦  “  ("  -  TRIM(SHIPTYPE): 

♦  “  "  ♦  LTRIM<TRIM<STR<HULLNUMBER)>>  -  “>" 
cntr=cntr *l 
svalue=ulc 

ssvalue=IIF<prlorlty='  •) 

ENDIF 

IF  sevalneRprlorlty  IF  new  priority 

cntr=cntr*i 
IF  cntr>pagelen-9 

DO  COBEAD  WITS  cntr.adate.pageno 

ENDIF 

8  cntr.  aargln  SAY  "Priority  "  *  TRIM(PRINAME)  *  "  Requisitions" 

8  cntr  +  i.O  SAY 

cntr=cutr*2 

savalna=prlorlty 

ENDIF 

*  -  print  naxt  record 

8  cntr.  0  SAY  UIC  ♦  +  LTRIM(STR(  ROND  ATE))  +  ♦  SERIAL 

8  cntr.  aargln*  32  SAY  NOMEN 

8  cntr.  aargln*  92  SAY  nun 

e  cntr.  aargln*  67  SAY  OTY 

8  cntr.  aargln*  76  SAY  UI 

8  cntr*l, aargln*  0  SAY  ACTYNAME 

8  cntr*l, aargln*  92  SAY  EQUIPMENT 

8  cntr*l, aargln*  69  SAY  woRKCENTER*”-"* JSN 

8  cntr*2. aargln*  0  SAY  STATUSNAME 

8  cntr*3. aargln*  0  SAY  REMARKS 

cntr=cntr*9 

SKIP 

*  - bottoa  of  page  proceaalng 

IF  cntr>pagelen-3 

cntr=0 

ENDIF 

ENDDO 

EJECT 

SET  DEVICE  TO  SCREEN 
SET  DELETED  OFF 
CLOSE  DATABASES 
RETURF 


*************************************** 

*  COBEAD.  PRG  * 

♦  Print  title  and  heading  for  CO  report* 
*************************************** 

PARAMETERS  cntr.adate.pageno 

pageno=pageno+l 

PRIVATE  i.J 

9  3,  aargln  SAY  "Page  no.  "*LTRIM<STR(pageno.9>> 

8  3.  aargln*  70  SAY  adate 

8  a.  aargln*  26  SAY  "HOT  LIST  Requisition  Status" 

8  6.  aargln  Say  "REQUISITION  no." 

9  6.  aargln*  32  SAY  "NOMENCLATURE  STOCK  NMBR  QTY  l'I" 

9  7.  aargln  SAY  "ACTION  COMMAND" 

8  7,  aargln*  92  SAY  "EQUIPMENT  JSN" 

8  8.  aargln  SAY  "STATUS" 

8  9.  aargln  say  "REMARKS" 

cntr=ll 

RETURN 


*************************************** 

*  RPRRPT.PRG  * 

*  print  reports  for  RPPOs/Repalr  * 

*************************************** 

SET  DEVICE  TO  SCREEN 

atltle  =  “Prlnt  Reports  for  RPPOs  and  Repair  Divisions" 

DO  BORDERS  WITH  title,  stttle 

9  9.  9  SAY  "*****  *****  *  *  * 


******* 


#  10,  9  SAY  "*  *  *  *****  *  *  **  *  *  *•' 

0  n.  9  say  “*  **  *****  *  ****** 

0  12,  9  SAY  “*****  *****  ****  *  *****  ***" 

0  13,  9  SAY  “*  ******  *  ******" 

0  14.  9  SAY  “*  *****  *  ***  **»*“ 

0  21.32  SAY  "Pitas*  Stand  By" 

SET  DELETED  ON 

USE  IOTLIST  INDEX  HO f RPR 

adat*=dat*()  11  lnlttallz*  variables 

pageno=0 

pag*l*n=62 

cntr=o 


aargln=0 

svalue=IIF(workcenter='  ’) 

ssvalue=IIF(eadnser=’  ’> 

SET  DEVICE  TO  PRINT 

DO  while  .NOT.  EOF!)  S.I  loop  to  print  reports 

*  - top  of  page  processing 

IF  cntr=o  .or.  svaluetworkcenter 

DO  RPRREAD  WITH  cntr.adate.pageno 

ENDIF 

*  -  print  new  boat  if  neccessary 

IF  cntr=ll 

cntr=cntr*2 
IF  cntr>pagelen-d 

DO  rprhead  with  cntr.adate.pageno 

ENDIF 

0  entr.  aargln  SAY  "Work  center:  "  *  workcenter 

cntr=cntr*l 

svaluetworkcenter 

ssvalue=riF<enduser='  ') 

ENDIF 

IF  ssvaluetenduser  &&  If  new  enduser 

cntr=entr*l 
IF  cntr>pagelen-9 

DO  rprhead  with  cntr.adate.pageno 

ENDIF 

IF  ASCI  ENDUSER)  <98  ll  If  enduser  Is  a  boat 

0  entr.  aargln  say  "Jobs  for  USS  “  ♦  TRIM(SHIPNAME)  ♦  "  (“  ; 

-  TRIMISHIPTYPE)  ♦  "  “  ♦  LTRIMITR1M(STR(HULLNUMBER))>  -  ">“ 

ELSE  ll  If  enduser  Is  a  Tender  division 

0  entr.  aargln  SAY  "Jobs  for  "  *  ENDUSER 

ENDIF 

o  cntrtl.o  say  "" 

cutr=cntr*2 

ssvalue-enduaer 


ENDIF 

*  -  print  next  record 

0  entr.  0  SAY  UIC  *  t  LTRIMISTR(RQNDATE)) 

9 

entr.  aargln* 

32 

SAY 

NOMEN 

9 

entr.  aargln* 

92 

SAY 

NIIN 

9 

entr,  aargln* 

67 

SAY 

QTY 

9 

entr.  aargln* 

76 

SAY 

UI 

9 

entr  M. aargln* 

0 

SAY 

actyname 

9 

cntr*l. aargln* 

23 

SAY 

“Priority  “  ♦  priname 

9 

catr*l.aargln* 

92 

SAY 

EQUIPMENT 

0 

cntr*l, aargln* 

69 

SAY 

WORKCENTER*"-" *JSN 

0 

cat  r  *2. aargln* 

0 

SAY 

STATUSNAME 

9 

cn  tr  *3. aargln* 

0 

SAY 

REMARKS 

cutr=cntr*9 

SHIP 

IF  cntr>peg*len-3 
catr=o 

ENDIF 

ENDOO 

EJECT 

SET  DEVICE  TO  SCREEN 
SET  DELETED  OFF 
CLOSE  DATABASES 
RETURN 


i.1  bottoa  of  page  processing 


.(l  I!- 


,  .6*9  f,w  fc*  aA‘»A- Uk  j.t  a-*  tJ ■*.> <4.% 


Ik************************************** 

RPRHEAD.PRC 

•  Print  title  and  beading  forRPPOraport* 
*************************************** 


adate, pageno 


"Page  no.  "*LTRIM(STR(pageno,9)> 

SAY  adate 

SAY  "RPPO  /  Repair  HOT  LIST  Requisition  Status" 
"REQUISITION  NO." 

SAY  "NOMENCLATURE  STOCK  NMBR  QTY 

"ACTION  COMMAND" 

SAY  "PRIORITY" 

SAY  "EQUIPMENT  JSN" 

“STATUS" 

"REMARKS" 


PARAMETERS  cntr.i 
pageno= pageno* l 
PRIVATE  l,J 
0  3.  aargln  SAY 

9  3,  aargln*  70 

«  a.  aargln*  19 
9  6.  anrgln  SAY 

9  6,  aargln*  32 

9  7.  aargln  SAY 

9  7.  aargln*  23 

9  7.  aargln*  92 

9  a.  aargln  SAY 
9  9.  aargln  SAY 

cntr=ll 
RETURN 


*************************************** 

*  EXPRPT.PRG  * 

*  print  reports  for  EXPEDITER  USE  * 
*************************************** 

SET  DEVICE  TO  SCREEN 

stltle="Prlnt  nun  lists  by  Action  Activity’ 

DO  BORDERS  WITH  title,  stltle 

9  9.  9  SAY  ******  *****  *  *  *  *******  *  *  * 

9  10.  9  SAY  "*  *  *  *****  *  *  **  * 

9  11.  9  SAY  “*  **  *****  *  **** 

9  12.  9  SAY  ******  *****  *  ***  *  *  *** 

9  13.  9  SAY  “*  ******  *  *  *  ** 

9  H,  9  SAY  "*  *****  *  *** 

9  21,32  SAY  "Please  Stand  By" 

SET  DELETED  ON 

USE  HOTUST  INDEX  HOTB 

*  - initialize  variables 

s^ate=date<) 

pageao=0 

pagelen=62 

cntr=0 

aargln=9 

avalue=IIF(actlonacty  =  '  '.'*’.’  •) 

SET  DEVICE  TO  PRINT 
GOTO  TOP 

*  - —  loop  to  print  reports 

DO  WHILE  .NOT.  EOFO 

*  -  top  of  page  processing 

IE  cntr=0 

DO  EXPHEAD  WITH  entr. adate. pageno 

ENDIF 

*  -  print  new  action  activity  If  neccessary 

IF  avaiueeactlonacty  .or.  cntr=9 

cntr=cntr *2 
IF  cntr>pagelen-4 

DO  EXPHEAD  WITH  entr, adate, pageno 
ENDIF 

9  entr,  aargln  SAY  "Action  Activity  Naae:  “  ♦  ACTYNAME 

cntr=cntr*2 

avaiueeactlonacty 

ENDIF 

*  -  print  next  record 


***- 

*  *" 
****“ 


entr, 

aargln* 

0 

SAY 

NUN 

entr. 

aargln* 

0 

SAY 

NUN 

entr. 

aargln » 

12 

SAY 

QTY 

entr. 

aargln* 

18 

SAY 

UI 

entr. 

aargln* 

21 

SAY 

NOHEN 

catr. 

aargln* 

37 

SAY 

SHIPTYPE 

entr, 

aargln* 

46 

SAY 

UIC  ♦ 

"  ♦  LTRIMISTRIHULLN  UMBER)) 


a  A  a  a  • 


aMuwsiiu(njuu(MM!uiupuiun.viurwrnu 


•  catr,  aargln  +  62  SAY  TSN 

cntr=catr*2 

SKIP 

*  - —  bottoa  of  page  processing 

IF  catr>pagelaa-3 

catr=0 

END1F 

ENOOO 

EJECT 

SET  OEVICE  TO  SCREEN 
SET  DELETED  OFF 
CLOSE  DATABASES 
RETORN 


********0****************************** 

EXPHEAD.PRC 

*  Print  title  6  heading  for  EXPRPT  * 
***********************00*00 *********** 


PARAMETERS  cntr 
pageno=pageno+ 1 


9 

3.  aarglnt 

0 

SAY 

“Page  no.  “  ♦  LTRlM(STRlpageno.S)) 

9 

3.  Margin* 

98 

SAY 

adate 

9 

4.  Margin* 

9 

SAY 

"HOT  LIST  Outstanding  Requisition  List  (by  Action 

♦  "  Activity)" 

9 

6,  Margin* 

0 

SAY 

“NIIN“ 

9 

6,  aargln* 

14 

SAY 

"QTY“ 

9 

6.  ear  gin* 

18 

SAY 

"01“ 

9 

6.  aargln* 

21 

SAY 

“NOMENCLATURE" 

9 

6.  aargln* 

37 

SAY 

“UNIT  NO." 

9 

6.  aargln* 

46 

SAY 

"requisition  no." 

9 

6,  aargln* 

62 

SAY 

"TSN" 

cntr=8 

RETURN 


*************************************** 

»  NIINRPT.PRC  * 

*  prlat  report  of  outstanding  nuns  * 
*************************************** 

SET  DEVICE  TO  SCREEN 

atltle="Prlnt  niin  lists  for  Expediter  Use" 

DO  BORDERS  WITH  title,  stltla 

•  9,  9  SAY  "****•  *****  *  *  *  *******  *  *  * 

•  10,  9  SAT  "********  *  *  ** 

•  11,  9  SAY  "*  **  *****  *  *** 

0  12.  9  SAY  ******  *****  *  *  *  *  *  **** 

0  13,  9  SAY  "*  ******  *  *** 

O  14.  9  SAY  “*  *****  *  ** 

0  21,32  SAY  “Please  Stand  By' 

SET  DELETED  ON 

USE  H0TL1ST  INDEX  HOTEXP 

•  -  Initialize  variables 

adata=date(> 

pageno-0 

pagelea=<2 

catr*o 

aarglneS 

dvalue=IIF(stockcntrl-'  ’) 

SET  DEVICE  TO  PRINT 
GOTO  TOP 

•  - loop  to  print  reports 

DO  WHILE  .NOT.  EOFO 

*  - top  of  page  processing 

IF  cntr*0 

DO  NIINHEAO  WITH  cntr.adate.pageno 

ENOIF 

*  - -  print  new  stock  status  If  neccessary 

IF  NIIN*SPACE<11) 

SKIP 


***“ 

*  *’■ 
***** 
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LOOP 

ENDIF 

IF  dvalnetstockcntrl  .or.  cntr=8 
cntr=cntr*2 
IF  catr>pagelen-4 

00  NIINBEAD  with  cntr.adate.pageno 
ENDIF 

•  cntr.  aargla  SAY  “The  following  requisitions  were:  "  *  why 

catr=catr*2 

dvalnetstockcntrl 

ENOIF 


print  next 

rec 

:ord 

9  cntr. 

aargln* 

0 

SAY 

NIIN 

9  cntr. 

aargla* 

0 

SAY 

NUN 

9  cntr. 

aargln* 

12 

SAY 

QTY 

9  cntr. 

aargln* 

18 

SAY 

UI 

9  cntr. 

aargln* 

21 

SAY 

NOMEN 

9  cntr, 

aargln* 

37 

SAY 

SHIPTYPE  ♦  “  “  ♦  L  T  RIM  <STR<  HULL  NUMBER!) 

9  cntr. 

aargln* 

46 

SAY 

OIC  *  ♦  LTRIM<STR<RQNDATE»  ♦  ♦ 

9  cntr. 

aargln* 

62 

SAY 

TSN 

cutr=cntr*2 

SKIP 

*  — - bottoa  of  page  processing 

IF  cntr>pagelen-3 
cnlr=0 

ENDIF 

ENODO 

EJECT 

SET  DEVICE  TO  SCREEN 
SET  DELETED  OFF 
CLOSE  DATABASES 
RETORN 


*************************************** 

*  NIINBEAD. PRG  * 

e  Print  title  l  heading  for  NUN  List  * 
*************************************** 

PARAMETERS  cntr.adate.pageno 
pagenospageno+1 


9 

3. 

aargla* 

0 

SAY 

“Page  no.  "  *  LTRIM<STR<pageno,9>) 

9 

3. 

aargla* 

96 

SAY 

adate 

9 

4. 

aargln* 

19 

SAY 

"HOT  list  outstanding  NUN  List" 

9 

6. 

aargln* 

0 

SAY 

"NIIN" 

9 

6, 

aargln* 

14 

SAY 

"QTY" 

9 

6. 

aargln* 

18 

SAY 

"UI“ 

9 

6. 

aargln* 

21 

SAY 

"NOMENCLATURE" 

9 

6, 

aargln* 

37 

SAY 

"UNIT  NO." 

9 

6. 

aargln* 

46 

SAY 

"REQUISITION  NO." 

9 

6. 

margin* 

62 

SAY 

“TSN" 

cntr=e 

RETURN 


*************************************** 

*  DELRPT.PRG 

*  print  reports  of  Deleted  Reqns  * 

*************************************** 

SET  DEVICE  TO  SCREEN 

stltlet'Prlnt  NUN  lists  of  Inactive  Requisitions" 

DO  BORDERS  WITH  title,  Stltle 

*  *  *  *******  *  *  * 
*  **  *  *  *  ** 
****  *  *** 

*  ***  *  *  *  * 


***** 

* 


9,  9  SAY  "***** 

10,  9  SAY  "*  * 

11,  SAY  "*  *  * 

12,  9  SAY  “»****  ***** 

13,  9  8 AY  "*  * 

14,  9  SAY  “*  * 

21.32  SAY  "Please  Stand  By" 

USE  BOTLIST  INDEX  BOTEXP 
•  - Initialize  variables 


** 


****" 

*  *" 

*•• 

*  *  *  *  •• 

*  *•• 


*  *  *  *  •• 
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adate*date<) 

aaganoso 

pagalaa=82 

cntr=0 

aargln=9 

dvalae°IIF!stockcntrl=’  ’) 

SET  DEVICE  TO  PRINT 
«OTO  TOP 

*  — - loop  to  print  reports 

00  WHILE  .NOT.  EOF!) 

* - top  of  page  processing 

IF  catr>0 

DO  DELIEAD  WITH  cntr.adate.pageno 

ENDIF 

IF  .aot.  DELETED!) 

SKIP 

LOOP 

ENDIF 

» - print  new  stock  status  If  neccessary 

IF  dvalnagatockcntrl  .or.  cntr=8 
cntr=cntr*2 
IF  cntr>pagelen-4 

do  delhead  with  cntr.adate.pageno 
ENDIF 

g  cntr.  aargln  SAY  “Reason  for  non-issue  was:  "  ♦  stockcntrl 

catr>cntr*2 

dvalue-stockcntrl 

ENDIF 


print  next 

rec 

:ord 

•  cntr. 

aargln* 

0 

SAY 

NUN 

g  cntr, 

aargln* 

0 

SAY 

NUN 

g  cntr. 

aargla* 

12 

SAY 

QTY 

g  cntr. 

aargln* 

18 

SAY 

UI 

g  cntr. 

aargln* 

21 

SAY 

NOMEN 

g  cntr. 

aargln* 

37 

SAY 

SHIPTYPE  ♦  “  "  ♦  LTRIM(STR(HULLNUMBER)> 

g  cntr. 

aargln* 

46 

SAY 

UIC  ♦  *  LTRIM<STR!RQNDATE>>  *  * 

g  cntr. 

aargln* 

62 

SAY 

TSN 

cntr=cntr*2 

SKIP 

*  — - bottoa  of  page  processing 

IF  cntr>pagelen-3 
cntr=0 

ENDIF 

ENDDO 

EJECT 

SET  DEVICE  TO  SCREEN 
CLOSE  DATABASES 
RETURN 


SERIAL 


*************************************** 
*  DELHEAD.  PRG 

*  Print  title  &  heading  for  ')EL.  l  1st  * 


PARAMETERS  cntr,»d 
peg tno=pag t no* 1 


3. 

aargln* 

0 

SAY 

“Page  no.  “  *  LTRIM(STR(pageno.s)> 

3. 

aargln* 

98 

SAY 

adate 

4. 

aargln* 

18 

SAY 

"HOT  LIST  Inactive  Record!  List" 

6. 

aargla* 

0 

SAY 

“NIIN" 

6. 

aargln* 

14 

SAY 

"9TY“ 

6, 

aargln* 

18 

SAY 

“UI" 

6. 

aargla* 

21 

SAY 

“NOMENCLATURE" 

6. 

aargln* 

37 

SAY 

"UNIT  NO." 

6. 

aargla* 

48 

SAY 

"REQUISITION  NO." 

6. 

aargln* 

82 

SAY 

"TSN" 

cotrxe 

RETURN 


k 
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-•a.  a  l.t  »  I 


************************************* 


BOTLIST.BAT 

*  prograa  to  boot  BOTLIST  froa  DOS 


************************************* 


echo  off 
cd  C:\BL 
DBASE  MAINHENU 

cd  C:\ 


aaaaaaaaaaaa 


*  HLINSTAL.BAT 

*  prograa  to  Inatal  BOTLIST  to  dlak  * 
************************************* 

ECBO  OFF 

ECBO  iaatalilag  BOTLIST  Report  Prograa 
ECBO  Pleaao  staad  by  .  .  . 

C: 

cd  C:\ 

ad  BL 

copy  A:BOTLIST.BAT  C: 

copy  C:CONFIG.SYS  C:CONFIG.OLD 

copy  C:CONFIG.SYS  +  A:CONFIG.NEW  C:CONFIG.SYS 

copy  ^AUTOEXEC.BAT  OAUTOEXEC.OLD 

copy  C:AUTOEXEC.BAT*A:AUTOEXEC.NEW  C:AUTOEXEC.BAT 

copy  a:*.PRC  C:\BL 

copy  A:*. DBF  C:\IL 

copy  A:*.NDX  C:\BL 

ECBO  BOTLIST  Report  prograa  Ioatallatlon  Coaptate. 

ECBO  Roaovo  disk  froa  drive  a  and  REBOOT  Systea. 

ECBO  ON 


*********************************** 


CONFIG. NEW 

*  lines  to  add  to  CONFIG.SYS  * 

*********************************** 


FILES-20 

BUFFERS=19 


*********************************** 


AUTOEXEC. NEW 

*  lines  to  add  to  AUTOEXEC.BAT  * 
*********************************** 


PATB  C:\:C:\DB3P 


*********************************** 


BLREMOVE.BAT 

*prograa  to  reaove  BOTLIST  fa  disk* 


*********************************** 


ECBO 

CLS 

ECBO 

ECBO 

ECBO 

ECBO 

ECBO 

ECBO 

PAUSE 

CLS 

ECBO 

ECBO 

ECBO 

PAUSE 

CLS 

C: 

ECBO 

ECBO 


WARNING:  This  prograa  will  DELETE  ALL  flies  associated  with  the 

BOTLIST  Report  Prograa.  If  you  do  not  want  to  delete  those  files. 
Press  ’CTRL-C’  (at  the  saae  tlae)  to  EXIT  froa  this  prograa. 
To  continue  with  the  BLREMOVE.BAT  prograa.  Press  any  other  key. 


.  i  ■  .  i  i  .  i  i  •  .  i  i  .  .  ■  i  i  ■  i  i  i  i  .  >  i  .  . 


WARNING:  This  Is  your  last  chance  to  prevent  loss  of  files. 

Press  ’CTRL-C’  to  abort  and  prevent  loss  of  files. 

Press  any  other  key  to  reaove  all  BOTLIST  files  t  prograas  froa  disk. 


****************************** 


n’*  a*"  »*«  s^  a 


r.  lU  I'.  «>.  !<■  »■.  f.  l'.  l‘«  1'.  I*.  iVl1.,!'. 

Appendix  B:  Glossary  of  Acronyms 

ADP 

automated  data  processing 

AFIT 

Air  Force  Institute  of  Technology 

AS 

auxiliary-submarine  (submarine  tender  -  type  ship) 

AUTOVON 

automated  voice  network  communications  system 

CAPT 

Captain 

CDR 

Commander 

CO 

commanding  officer 

COMSUBLANT 

Commander,  Submarine  Forces,  Atlantic 

t 

> 

CONUS 

continental  United  States 

DBMS 

data-base  management  system 

DOS 

disk  operating  system 

ENS 

Ensign 

FBM 

fleet  ballistic  missile  (or  fleet  ballistic  missile  submarine) 

r 

f 

f 

IMMS 

integrated  maintenance  management  system 

i 

/ 

4 

i 

JCN 

job  control  number  (work  center  code  +  JSN) 

JSN 

job  sequence  number 

LCDR 

Lieutenant  Commander 

LT 

Lieutenant 

I 

LTJG 

Lieutenant  (junior  grade) 

s 

MIS 

management  information  system 

NAVSUP 

Naval  Supply  Systems  Command 

J 

NAVDAC 

Naval  Data  Automation  Command 

3 

NC 

not  carried 

> 

> 

< 

NIIN 

national  item  identification  number 

n 

» 

p 

146 

•j 

V 

s" 

• 

V 

V> / A.’ 

V 

NIS 

not  in  stock 

NS 

non-standard  (non  stock-numbered) 

NSN 

national  stock  number 

PMA 

production  management  assistant 

PMOLANT 

Polaris  Missile  Office.  U.S.  Atlantic  Fleet 

PNIS 

partial-not  in  stock 

RAM 

random  access  memory 

ROVSS 

repair  of  other  vessels  supply  support  division 

RPPO 

repair  parts  petty  officer 

SNAP  I 

shipboard  non-tactical  ADP  program  (for  large 

ships) 

SNAP  II 

shipboard  non-tactical  ADP  program  (for  small 

ships) 

SUBSAT 

submarine  supply  assistance  team  division 

SSBN 

fleet  ballistic  missile  submarine 

UIC 

unit  identification  code 

USN 

United  States  Navy 

uss 


United  States  Ship 


Appendix  C:  Definitions  of  Terms 


database 

deployment 

Electronics 

Technician 

expediter 

file 

fleet-wide 

floppy  disk 

hard  disk 

hotiist 

Hull  Technician 

management 

operator 

rating 

refit 

requisition 


A  group  of  logically  related  files  or  data-sets. 

A  mission  that  involves  sending  a  ship  or  submarine  to 
sea  for  an  extended  period  of  time. 

Enlisted  rating  specializing  in  repair,  operation,  and 
maintenance  of  electronics  equipment. 

Storekeeper  from  SUBSAT  or  ROVSS  who  monitors  high- 
priority  requisition  status  and  does  stock  system  searches 
to  locate  and  obtain  needed  parts  more  quickly. 

A  collection  of  related  records,  sometimes  called  a  data¬ 
set. 

Covering  or  applying  to  the  entire  Navy  or  appropriate 
portions  of  the  Navy. 

A  thin,  portable  mylar  disk  used  to  store  data  and  soft¬ 
ware  for  use  in  computer  operation. 

A  permanent  component  of  a  computer  system  used  to 
store  data  and  software  for  use  in  computer  operation. 

A  listing  of  priority  1  (highest  priority)  requisitions 
from  a  submarine  tender  or  supported  unit  that  shows 
descriptive  data  as  well  as  latest  status. 

Enlisted  rating  specializing  in  repair  and  construction 
of  major  ship  components,  particularly  those  constructed 
with  metal  sheeting. 

A  method  of  collecting,  organizing,  storing,  arid  correla¬ 
ting  information  for  the  support  of  planning,  controlling, 
and  operating  system  functions  of  an  organization. 

The  person  who  directly  inputs  information  into  the 
computer,  and  prints  reports  from  the  data  base. 

Enlisted  occupational  specialty. 

A  process  of  overhauling,  supplying,  and  repairing  a  sub¬ 
marine  on  a  scheduled,  fixed-time  basis. 

A  request  for  supplies  or  repair  parts. 


ship's 

supervisor 


The  person  designated  onboard  a  Tender  to  oversee  the 
refit  of  a  specific  submarine. 


squadron  A  group  of  ships  or  submarines  operating  under  a  single 

Commander  (Commodore)  as  a  unit. 

stock-check  The  process  of  searching  stock-on-hand  inventories  to 

locate  needed  items  for  outstanding  requisitions. 

Storekeeper  Enlisted  rating  specializing  in  the  ordering,  receipt. 

maintenance,  and  issue  of  supplies. 

tended-unit  Ship  or  submarine  supported  administratively  and  opera¬ 

tionally  by  a  tender. 


tender 


A  ship  designed  to  support  a  squadron  of  ships  or  sub¬ 
marines  by  providing  all  repair,  supply,  communications 
and  administrative  equipment  and  technology  required. 


Appendix  Dj  Interview  Questions 


Interview  Questions  for  Supply  Officers 

1.  Do  you  use  the  HOTLIST  REPORT  provided  by  PMOLANT? 

2.  If  so,  how  do  you  use  it? 

3.  Who  uses  it  besides  the  Supply  Department? 

4.  Does  your  Supply  Department  produce  any  sort  of  hotlist  other  than 
the  one  provided  by  PMOLANT? 

5.  If  so.  why? 

6.  To  whom  do  you  provide  a  hotlist? 

7.  If  you  had  an  efficient  method  to  produce  your  own  hotlists.  would 
you  use  it?  How? 

8.  Is  there  anyone  for  whom  you  would  like  to  produce  a  hotlist  that  you 
presently  cannot,  due  to  lack  of  equipment,  personnel,  or  any  other 
reason? 

9.  If  you  could  produce  hotlists  in  formats  other  than  that  provided  bv 
PMOLANT.  what  would  they  look  like? 

10.  If  you  could  produce  hotlists  in  other  formats,  who  would  you  want  to 
produce  them  for? 


Interview  Questions  for  Repair  Officers 

1.  Does  your  Supply  Department  provide  you  with  any  sort  of  supply-parts 
hotlist  for  refit  priority  1  requisitions? 

2.  Does  it  tell  you  what  you  want  to  know? 

3.  What  does  it  lack  that  would  help  you  do  your  job? 

4.  Is  it  in  a  format  that  meets  YOUR  needs? 

5.  Is  it  produced  often  enough  for  your  needs?  Too  often? 

6.  Is  the  hotlist  broken  down  to  a  level  that  is  useful  within  your  work- 
centers?  If  not.  would  you  want  it  to  be? 

7. 


What  changes  would  you  like  to  see  in  it  if  they  were  possible"? 


The  HOTLIST  Report  Program  is  an  easy-to-use  Before  attempting  to  start  the  HOTLIST  Report 

program  designed  to  provide  IJ.S.  Navy  FBM  SUBSAT  Program,  first  make  sure  that  it  has  been  installed 

and  ROVSS  offices  with  a  simple  method  by  which  using  instructions  on  page  3. 

they  may  input  critical  Hot  List  requisition  data  and 

easily  generate  a  variety  of  reports.  These  reports  Read  this  book  carefully  before  beginning. 
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